Currently in the mac vm drawing to the screen is a long laborious  
project

You bitblt to the squeak display object, then a request is made to  
update the real screen.
see Interpreter>>displayBitsOf: aForm Left: l Top: t Right: r Bottom: b

That invokes the VM's ioShowDisplay which is responsible for dragging  
bits out of the
Squeak Object Memory and splashing them onto a media that people can  
see. This involves
calling Apple's CopyBits to move the bits in os-9 and os-x.

Now the interesting & slow os-x parts comes in, For os-x we need to  
call QDFlushPortBuffer to
flush the bits to the screen, why? Well because os-x uses double  
buffering and alpha blending for everything visual.
So that involves figuring out any alpha-blending, then again copying  
data here and there before it becomes visual.

Right now we flush for every draw event, I've attempted to flush say  
every 1/60 of second, but interestingly enough that results in less  
pleasing morphic animations.

So as many folks have complained this process takes an extra-ordinary  
long time!!! OS-x has nice 'slow' eye candy.

Beta versions of os-x had a window type to exclude double buffering,  
but this was withdrawn in the 10.0.0 release. I have consider what is  
required to fake Squeak into drawing directly to the screen, which is  
something the ARM version does, but have not yet
figured out a decent method to do that, anyone interested might want to  
talk to me.


> It gets weirder when you just run the "Squeak 3.5.2b1 Classic" (taken  
> out of the package) in the Classic environment. It has nearly the same  
> fast timing as when started under OS9 even though a restore Display in  
> that environment takes nearly 2s!
>

The Squeak 3.5.2b1 Classic is just a CodeWarrior compiled version of  
the squeak VM for the os-9 environment (non-carbon), it's stuck in an  
application package for people who switch back and forth from os-9/os-x  
so they can double-click on just one icon and the application loader  
figures out which one to run based on the hosting os. dragging it out  
of the application package, then disposing of the package is a viable  
thing to do.

OS-9 classic mode does not do double-buffering, but I understand that  
is changing in upcoming versus of os-x classic support, wonder how that  
will change performance for classic mode?

On Tuesday, August 5, 2003, at 09:40  AM, Colin Putney wrote:

>
> On Tuesday, August 5, 2003, at 08:13  AM, Karsten Wolf wrote:
>
>> Hi,
>>
>> has anybody investigated the BitBlt performance difference in  
>> line-drawing between OS-9 and OSX?
>>
>> Any ideas?
>
> Just a wild guess, but it could be because Apple as been optimizing  
> CopyBits() in Classic for close to 20 years. That code probably had to  
> be rewritten for Quartz.
>
> Colin
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===