Morphic redraw question
cgreuter at calum.csclub.uwaterloo.ca
Wed Jun 24 19:35:34 UTC 1998
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