Folks -

Here are a couple of problems I've noticed, and which I would love to clean up right now.  I enjoy such projects in much the same way that I enjoy the puzzles in the Sunday paper.  However, right now I have other projects going on that I don't want to slight.  It occurred to me that some other eager Squeakers out there might equally enjoy the challenge, and the jobs might get done sooner if I gave them away.  So, here they are (these all happen to be morphic)...

Have you noticed the new preference, debugShowDamage?  It flashes every part of the screen that gets rewritten during morphic's display cycle.  Turning this preference on will be very useful for these projects.

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.

2.  Open any two browsers.  Click first in one, then the other.  Note that the entire window gets repainted not once but twice.  Fix this.

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.

[A word about morphic damage management:  The damage manager will merge intersecting rectangles.  If you know that an entire region needs to be repainted, you can report that at the beginning with self changed, or self invalidRect: someRect, and this will frequently cause a more effective grouping of damage rectangles.  You may find some code that forces a redraw to flush the damage set.  The invalidRect: method is a better approach, and you may wish to change the old code].

4.  Open one morphic project within another.  Enter the sub project.  Then return to the previous project.  Notice that on each transition the project entry code painstakingly paints the entire screen for the new project, and then repaints it once the project is entered.  Fix this.  Check it with both settings of the projectZoom preference.

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.  Fix this.  Now use the halo resize control.  Notice how much slower this is.  Fix this.  Now open a PDAMorph.  Resize it.  Make it so the monthMorph fits its pane properly.  Now one more thing (but it may be fixed by the time you get to this):  when you first open a PDA (with pop-out scrollbars), move the cursor in and out of one of the panes on the left.  Notice that it invalidates the entire upper left quadrant of the screen.  Now resize the category pane, using the little yellow pane boundary handle.  Notice that entering and leaving the left panes no longer invalidates the outer screen.  Make it so this is true from the beginning.

People sometimes comment that morphic seems unduly slow.  It's now wonder, given some of these problems.  If we make it through the puzzle page this month, I think things will start to feel a good bit faster.

It's probably worth announcing to the list your intentions to solve any of these so we can work together (teamwork can be fun and effective here), or at least avoid duplication of effort.

Have fun!

	- Dan