On Jan 24, 2005, at 10:32 AM, Tim Rowledge wrote:

> More 'realistic' tests would provide a better evaluation of the real
> impact of the speed of getting pixels from Display to Glass. Then we
> get a better idea of how much effort is worth putting in to which
> parts. Let's not get lost in details until we know if they're important
> details.
>
> tim

Tim the important detail here is once on the carbon OS-X VM I go over  
200 display flushes per second
then it seriously impact performance of an animation. This as you point  
out is not:

a) The same issue on all platforms
b) Triggered by general usage.

However as a special case it's interesting to note and leads to  
decisions how to get around this bottleneck.
In early versions of os-x they allowed you to have non-buffered  
windows, that isn't available anymore, so
some exploration is required. The key thing is to avoid impacting  
general usage, yet improve pixel level drawing.

In retrospect the solution is not any different from what I looked at  
in the squeak drawing layer a few years back where I changed
bitblit/interp.c to reduce the amount of drawing requests to  
ioShowDisplay.  However that was a general VM drawing change, versus  
this
which is platform specific.

It would be interesting to know given your example what the performance  
is like on windows and other platforms?

I'll note the unix VM Squeak-3.6-3.app under OS-X give similar  
behavior/performance as the carbon VM 3.8.5b1

> --
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===