The Puzzle Page

Raab, Andreas Andreas.Raab at disney.com
Thu Dec 14 21:31:53 UTC 2000


Hi Dan,

> 1.  Open, eg, a browser (with pop-out scrollbars).  Move your 
> cursor in and out of a list pane, and notice that the 
> contents do not get rewritten (no damage flash).  Now move 
> your cursor in and out of a text pane.  Notice that the 
> entire text contents gets rewritten.  Although the region of 
> the selection does get redisplayed, it should not bve 
> necessary to repaint the entire text area.  Fix this.

I think it's related to the selection drawing. Notice that the entire pane
gets redrawn when you move the cursor within (e.g., through the cursor keys)
and that since the cursor is shown when you enter the pane I think this is
the same issue.

> 3.  Open a browser.  Collapse it.  Expand it.  Note that the 
> entire merge of the before and after rectangles gets 
> repainted.  Also, if you slow it down, it looks like even 
> more happens when collapsing a system browser.  Fix this.

This problem is in Morph>>bounds: which splits between positioning and
resizing. What happens is somewhat along the lines of "first move the system
window with fully expanded to the collapse point then make it smaller". No
wonder that it invalidates the entire region.

> 5.  Open a MonthMorph, and notice its behavior when you 
> change its extent using the morph menu resize command.  
> Notice that it repaints the entire region of the screen from 
> screen topLeft to the bottomRight of the MonthMorph.

Short answer: Global coordinates. E.g., what happens in many places is
	someMorph addMorph: someOtherMorph new.
	someOtherMorph position: someMorph position.
[note that the positioning part may be implicit due to layouting]. So when
the morph is first added it starts at 0 at 0 and when it is moved it moves to
some other position. But naturally, the invalidation starts at 0 at 0.

  - Andreas





More information about the Squeak-dev mailing list