Morphic redraw question

Chris Reuter cgreuter at
Wed Jun 24 19:35:34 UTC 1998

Hi all,

I'm writing an application with a Morphic GUI.  The display
contains a widget that's subclassed from RectangleMorph and uses a
Form to store the actual picture.  When the app. wishes to display
something new, the changes are all drawn on the Form and then
#changed: is called on the morph to force a redraw.  The #drawOn:
method simply copies the form to the display.

The problem with this arrangement is that it's a bit too slow.  An
easy optimization is available however.  Since usually, only a small
subset of the display needs to be redrawn, I can override
#invalidRect: to keep an OrderedCollection of changed rectangles
around and get #drawOn: to only draw over those.  (I didn't
discover DamageRecorder until later.)

The problem with this scheme is that the multiple sends of
#invalidRect: aren't enough to cause the widget to be redrawn.  It
seems that only #changed: will do that, even though all #changed: does
(by default) is send #invalidRect: with the morph's bounds as its
argument, which makes the optimization moot.

So, my questions are:

        1) Is there any way to cause a morph to be redrawn without
        invalidating the whole thing?

        2) What normally triggers the redrawing of a morph?

Thanks in advance,


PS: I would like to thank the Squeak team for producing such a great
Smalltalk system.  I continue to be impressed by it.

More information about the Squeak-dev mailing list