Well the problem is really related to calling the flush api every  
screen draw (when asked). The b hilbert: 7 side: 2 does *lots* of
pixel drawing resulting in flush events (*lots*) This takes seconds  
(*lots*)  Way too many lots here...

So I went back to visit the apple documentation again and think again.

Ah, what if I was to add the rect to the dirty region, then flush every  
N milliseconds. I believe in the past I tried this at 60 times/sec but  
didn't like the results.
So what if I tried it at 200 times/second?

Ah, that seems ok, and it buzzes thru Tim's suggestion in 2.1 seconds,  
versus the 59 seconds a 3.8.5b1 VM takes.

Now the problems:

a) sometimes a flush is left pending, not sure why since the dirty  
region should be flush occasionally (perhaps not occasionally enough?)
      Well I could do something about that if needed.

b) We crash when we get a thread race condition on the runloopObserver  
FlushAllBuffers() which attempts to flush the window, when we at the  
same time are attempting to flush the window. That requires reading to  
solve.



On Jan 22, 2005, at 11:16 PM, Hans-Martin Mosner wrote:

> Karsten Wolf wrote:
> ...
>
>> To restate the "obvious": Squeak is fast. Or more precicely: some  
>> aspects of the OS-interface are  ehm sub-optimal... worth having a  
>> second or third look at.
>>
> /me wonders what hidden pathes to the screen are used by the DVD and  
> MPEG players - these seem to be able to shuffle pixels to the screen  
> fairly fast.
> Might be reasonable to look there for a solution. Think of Squeak as  
> just another media player with a slightly different kind of media :-)
>
> Cheers,
> Hans-Martin
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===