Devin Hosea <alumni.princeton.edu at dhosea> writes:

> True enough.  This is essentially the same concept though, as storing
> all graphics operations to the window, except it is done at the pixel
> level. I'm not sure which is faster?  There is another post I read
> with regard to the gworld fix done in MCL 3.9.  That's good too.  In
> short, however, all of these fixes work around the native toolbox
> view-refresh mechanism, which sucks, and is incredibly inefficient.
> 
> Professionals (I mean, Microsoft, etc) have ways of working around it
> that are better than these kludges.  Perhaps someone could find out
> something from them.

Um, no. The Mac toolbox's native view-refresh mechanism is in fact quite
efficient. That's why it's called Quickdraw. Blockmove bitblt copying of
pixels from an offscreen bitmap to video memory (which is what Quickdraw
gworlds allow) is generally about as fast as you can go without extremely
esoteric (and rare) video refresh hardware which allocates discontiguous
video memory on a per-window basis. 

Saving picture commands and replaying them may be faster in certain
limited cases where there are very few elements in the picture or if you
have custom drawing acceleration hardware (something many personal
computers DO have). But its speed will always be dependent on the contents
of the drawing, whereas using gworlds will exhibit near constant-speed
refresh for windows of a given size. 

You have also complained about the lack of an auto-refresh mechanism
in MCL. In separate email, I recommended you check such examples as
scrolling-gworld-windows.lisp which appears on the MCL 3.9 CD-ROM,
for a way to build auto-refreshing windows. While it's true that this
functionality is not built in to MCL, loading this one file makes it
present.

As others have pointed out, MCL brings all lowlevel drawing
operations out to programmer control, with the attendant disadvantage
that you have to write the highlevel code (or load it from the
CD-ROM) to make higher-level functionality work. The advantage, of
course, is that gives you complete control over what goes on.

None of this implies any lack of speed or functionality on the part
of the Mac toolbox, so slamming the "native toolbox view-refresh
mechanism" is inappropriate.

Could you enlighten us as to exactly how "professionals" like
Microsoft (grin) do this faster and without such "kludges"?

-- 
Shannon Spires
<sandia.gov at svspire>