Lex,

Nice test but not informative enough. Please keep in mind that if there's a
difference between Squeak's display depth and the OS display depth all the
pixels must be converted (which is expensive). Also, on any Unixy machine
make sure you're running with XSHM. Oh, and give us an idea about how large
Squeak's display actually was. But all in all the number you're giving looks
too high (I would expect half of what you're showing and this may indicate a
problem with XSHM).

  Andreas

> -----Original Message-----
> From: Lex Spoon [mailto:lex at cc.gatech.edu]
> Sent: Wednesday, March 22, 2000 3:02 AM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: Re: Timers, Stepping, Co-routines and Riverdance in Squeak
> 
> 
> It sounds like you are simply seeing problems in Squeak 
> transmitting its
> screen to the video card.  Could you try the following and 
> see how long
> it takes?
> 
> 	[ Display forceToScreen: (1 at 1 extent: Display extent) ]
> timeToRun
> 
> On my computer (Linux, K6-3/333, TNT2-Ultra), this takes over 100
> milliseconds.  Thus if I ever foolishly try an animation that takes up
> the full srceen, I get a maximum of 10 frames per second just from the
> time needed to shove the bitmaps over to the X server and onto the
> display.
> 
> It would be interesting to hear how other platforms handle this.
> 
> Lex
> 
> 
> 
> Michael Stevens <mjstevens at mindspring.com> wrote:
> > 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.