Hi,

Finally found this message and now it's on the ftp sites.

cheers

bruce

On Mon, Jul 25, 2005 at 03:57:25PM -0700, John M McIntosh wrote:
> Ok, didn't get any feedback, but I'll assume it works ok, so could  
> someone push it to the ftp servers?
> 
> On 21-Jul-05, at 11:40 PM, John M McIntosh wrote:
> 
> >After pushing 3.8.8b5 out a few people let me know that there were  
> >problems with it.
> >
> >a) Hide, show all, hide other menu commands not working (actually  
> >this problem started in 10.4).
> >b) The CPU time taken as a background application went from 7% to 20%.
> >c) Drawing seemed to have an excessive lag time.
> >
> >
> >In poking at the menu command logic again I discovered that I was  
> >passing the hide/hide others/show cmd to the squeak event queue for  
> >Tweak Ffenestri processing, this was not a problem in 10.3.9  
> >because carbon was processing the resulting cmd (I handled it)  
> >incorrectly. This bug was fixed in 10.4, but then
> >exposed the problem in Squeak. The change is to ignore the hide/ 
> >show menu cmds and let the base carbon UI handle the behaviour.
> >
> >The window drawing was altered to flush every 1/50 of a second to  
> >satisfy changes to quickdraw in 10.4, and to address the fact that  
> >Quickdraw is going away. What I found was setting up the carbon  
> >event timer to flush all window every 1/50 of a second was too  
> >expensive. So I decided on a more radical approach and moved to  
> >Quartz for drawing the bitmap image.  I need to do this to take  
> >advantage of pending Quartz changes and for MacIntel.  Work earlier  
> >in the year showed me how to take Squeak bitmaps in 1/2/4/8 bits of  
> >color and use QuickDraw to convert to 16 or 32bit color before  
> >drawing, this was carried forward into the Quartz draw logic since  
> >we work with only 16 or 32 bits of color for the host window.
> >
> >Early Shark benchmarking shows that timing are similar to the times  
> >the Quickdraw memcpy logic gave us.
> >
> >Many late hours were taken to figure out how to flush the screen.  
> >First I did a GCSync operation after each draw which should trigger  
> >a flush about every 1/50 of a second, however this fails when the  
> >drawing area becomes very small say 1 pixel and is updated at very  
> >high rates. What I found is that I need to do a CGContextFlush  
> >every 100ms or so to make the drawing not lose sync.
> >
> >Feedback on the drawing changes are welcome. Things feel better and  
> >I think Croquet works faster?
> >
> >http://homepage.mac.com/johnmci/FileSharing.html
> >
> >or see the following ftp directory for the zip file.
> >
> >ftp://ftp.smalltalkconsulting.com/
> >
> >--
> >====================================================================== 
> >=====
> >John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> >Corporate Smalltalk Consulting Ltd.  http:// 
> >www.smalltalkconsulting.com
> >====================================================================== 
> >=====
> >
> >
> >
> >
> 
> --
> ======================================================================== 
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================== 
> ===
> 
> 

-- 
edoneel at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org