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
======================================================================== 
===