Morphic redraw question
johnm at wdi.disney.com
Fri Jun 26 01:09:29 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.
Just sending #invalidRect: with the right damage rectangles should
work--if the rectangles are right. Look at TinyPaintMorph for an
example of what you are trying to do. My guess is that you're damage
rects are falling outside the area of the actual change, so it
appears that nothing is happening.
Hope this helps.
P.S. You probably don't need your own DamageRecorder. The world
has one, which it uses to keep track of damage sent in by all its
More information about the Squeak-dev