Morphic slowness, was: Re: The Puzzle Page

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Tue Dec 19 09:49:20 UTC 2000


Dan Ingalls wrote:

> People sometimes comment that morphic seems unduly slow.  It's now wonder,
> given some of these problems.  If we make it through the puzzle page this
> month, I think things will start to feel a good bit faster.

A while ago I think I realized what is the cause of much of this perceived
slowness. When running simulated code in the debugger, sometimes the screen
redraw will be simulated as well. Then you see how things are redrawn.

It seems the Morphic strategy is this: bottom-up (visually), each morph in a
repainted area is asked to redraw itself. This is a simple & fool-proof
technique.

A more optimal technique is: top-down, give each morph the area(s) of itself
that need to be redrawn, and remove these areas from the areas given to
underlying morphs when they are asked to redraw themselves. I think this is
what most window systems do (the Mac at least).

The second technique means each pixel will be redrawn exactly once, and only
exactly that which needs to be drawn is actually drawn. It is harder to
implement. Another disadvantage is that it is harder to handle translucent
morphs (the stuff below needs to be drawn to render it correctly).

The first technique means that if you have say five browser windows stacked
on top of each other, first the background will be drawn (costly if you have
a background picture!), then the bottom-most browser will be completely
redrawn, both inside and outside the damaged area, regardless of whether it
is covered in part or completely by others. Then the next-bottommost one is
redrawn "on top of" the first one, also this one completely even if it is
covered etc., then the next one and so on. A large share of pixels will be
redrawn (& blitted) six times over in this case, on each update. With the
other technique, you can even avoid traversing the morph tree (e.g. list
morphs, text morphs) for hidden areas.

The Mac uses Regions for the second technique, but this is not necessary,
collections of rectangles will do. You don't even have to care about partial
redrawing for small and simple morphs (except that the blt must heed the
redraw rectangle it is given, so as not to mess up the screen).

And no, I don't have an imminent change set to release that does this ;-)

Any thoughts from the graphics mavens?

Henrik






More information about the Squeak-dev mailing list