Lex Spoon provided
> [...] a motivating example:
> 
>         MessageTally spyOn: [ World fullDrawOn: World canvas ]
> 
> On my computer, 73% of the CPU time is taken up by GrafPort>>fillRect:.
> Thus for the task of redrawing a typical display, less than 27% of the
> time is spent executing bytecodes.  (And it's probably not even that
> much).  From this quick test, the single biggest thing that could speed
> up Morphic redisplays is an even faster BitBlt.

There's another issue lurking nearby that we should not overlook,
which halted my use of Morphic for animated entity-relationship 
diagramming: a world redraw takes place in a single canvas, which 
is allocated as a single rectangle encompassing the full bounds 
of all morphs displayed in the world.  

A divide-and-conquer approach might improve Morphic performance 
for large (in extent) groups of morphs.  By this, I mean dividing 
up the area to be drawn into subrectangles for which a canvas can 
be allocated (and reused) without provoking histrionics from the 
garbage collector, or causing the underlying OS to begin paging,
or requiring higher initial allocations of memory for Squeak.  
Subrectangles which do not intersect the display may be skipped 
entirely.

We pause briefly for platform disclosure:
  -- Squeak 2.6 [this work was done several months ago]
  -- Pentium-II 450, 128 MB RAM
  -- ATI Rage Pro Turbo, 8 MB RAM
  -- WinNT 4, SP3

In my prototype, the frame rate was acceptable for a fairly large 
number of entities, as long as they were all crowded into a 
relatively compact region.  The "cartoon physics" and the model's
bookkeeping used about 20% of the CPU.  As the entities spread 
themselves out into a more viewable arrangement, the CPU usage 
quickly rose to 100% and then the frame rate declined.  Further 
experimentation revealed that the machine began to struggle with 
only a handful of entities if any of them passed appreciably beyond 
the bounds of a 1280x1024 display.  Being an unreasonable person, 
I wanted entities to arrange themselves on a landscape potentially 
several times larger than the screen on each axis.

My sense is that most of the people on the Squeak list who are
concerned with frame rates are focused on smaller windows than
I was (e.g. the miracle of Alice in a 320x240 window).  Has 
anyone played with farflung arrangements of morphs?  Am I missing 
an obvious optimization?

--Michael Stevens
  Not speaking for the Genomica Corporation

PS. Teaser for the Squeak-on-a-palmtop crowd:
    If we can get away from Single Large Rectangle Syndrome (and 
    especially if anyone gets around to implementing the Remote
    Frame Buffer protocol from VNC in Squeak), then even a RAM-
    constrained device like a PDA might be able to host large, 
    complex Morphic scenes with acceptable (although probably 
    not wonderful) performance.