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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com ====================================================================== =====
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com ====================================================================== =====
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org