MacOSX Performance

Michael Latta lattam at mac.com
Mon Jan 24 01:08:23 UTC 2005


Apple has some AGL calls that move bits fast from CPU to GPU memory.  
They are apple specific extensions.  That would be the first place I 
would look for this type of speed up.  But, the biggest issue is that 
the Squeak API (BltBit) does not define a flush operation that 
applications are required to call.  There is no defined point where 
updates are required, and before which they can be deferred implicitly. 
  As such you get lots of small updates because if the Display was 
really the display buffer this would be more efficient.  Probably the 
best solution for Squeak would be to use the OpenGL APIs and flush 
updates when the world cycles its display loop.  This would catch 99% 
of the cases and produce the best frame rate for most uses.  For 
animations that are not using Morphic stepping then explicit update 
calls at the end of each frame would be required.  Just another example 
of backward compatibility being a bitch.  The semantics of Squeak 
graphics is going to need updating to get optimal display performance.

Michael



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
>
>




More information about the Squeak-dev mailing list