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,
--Chris
PS: I would like to thank the Squeak team for producing such a great Smalltalk system. I continue to be impressed by it.
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,
--Chris
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.
-- John
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 submorphs.
squeak-dev@lists.squeakfoundation.org