On Jan 21, 2005, at 2:25 PM, Tim Rowledge wrote:

> Karsten Wolf <karstenwo at web.de> wrote:
>
>>
>> Am 21.01.2005 um 14:34 schrieb Stéphane Conversy:
>>
>>> I guess the problem comes from the display engine.
>>>
>>
>> Guessed right. Or more precisely It has to do with the fact that the  
>> vm
>> calls for a display update for every bitblt. Since these update calls
>> are interprocess calls on OSX (VM to WindowServer) they become very
>> expensive in terms of time if the vm does that for every pixel.
>
>> You're seeing the slowness especially when drawing lines. In that case
>> the display update is called for every pixel which brings the
>
> Wrong. Take a look at that code again.
> BitBltSimulation>primitiveDrawLoop.  & >showDisplayBits. Note the
> interpreter's use of deferDisplayBits. Note also that Morphic
> frequently displays to a backing Form and then does a screen update in
> a big chunk.
>
> Display update performance might well be a performance bottleneck, but
> not for your stated reasons.

Tim, actually Karsten a year or two back  looked seriously at how  
drawing is done and tried to
buffer screen updates in the macintosh os-x VM by reducing the number  
of calls to the flush api which is expensive.
He had sent me some suggestions but they had  side effects in animation  
effects so I never pushed them into the update stream.

I had a number of years back looked at this (might be different today)
http://www.smalltalkconsulting.com/papers/tipsAndThoughts/ 
codeFragments.html
See "Squeak deferred screen updates." When I was looking at an remote  
xwindow update issue with Squeak.

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