Jim,

If you can understand WorldState>>drawWorld:submorphs:invalidAreasOn:
then it's probably straightforward. But don't ask me ... I don't get a
thing in there. I actually believe it's worthwhile to rethink the entire
drawing strategy in the light of having many small portions which need
to be redrawn. The drawing strategy as implemented in the method appears
to work well for strictly rectangular areas where #areasRemainingToFill:
returns either "all-or-nothing".

Considering a different redrawing strategy, I would go for an approach
where see morphs as "layers" rather than morphs, e.g., just assume that
we have a bunch of layers that should be restored in top-down order.
Then, we have to traverse all layers and on our way down we wish to
eliminate all the portion of the pending damage regions that are known
to be restored by the current layer (morph) and pass the remaining
remaining damage to the next layer below. Once we're at the bottom, we
draw the world's background in the damage regions. On our way up, we
draw each layer with the damage rectangles that were passed in by the
sender. Simple eh?! ;-)

Issues to consider:
* The damage passed in should be filtered at each layer to only redraw
those damage regions that overlap with the morphs full bounds
* Layers should be skipped quickly if no damage area overlaps the morph
at this layer (e.g., having a bunch of morphs in "front" but outside a
damage region should have a shortcut)
* Redrawing morphs with a LIST of damage rects could _heavily_ improve
performance. The damage rects would need to applied at the "primitve"
level, e.g., GrafPort might be able to handle the operations. For the
general case it could be implemented by just drawing the entire morph
repeatedly. [Side note: this should also improve Nebraska performance
since the damage rectangles would be transmitted once as well as the
drawing operations].
* The top-down drawing method should be implemented in class Morph so
it's accessible for all morphs which want to implemented #fullDrawOn: by
using the top-down drawing strategy (WorldState's method is nothing but
a different way to implement #fullDrawOn: - and there is absolutely
nothing World specific about it)

How much to expect from such a change?! Hard to say exactly (I'm still
waiting for test cases that show the slowdown for rounded corners).
However, overdraw being one of the major slowdowns in computer graphics
I guess its reasonable to expect the slowdown for (at least) the case of
rounded corners to be virtually unnoticable. A good test case might be
to use an arrangement of RectangleMorphs which mimick overlapping
windows and have various operations (moving, resizing, invalidating)
occur on random elements.

Ah, yes, and here's a neat little trick if you want to work on it: When
you are trying to implement such a crucial method you should
* duplicate the #drawWorld:... as #drawWorld2:...
* add a line in #drawWorld:... saying
	self doOnlyOnce:[^self drawWorld2: ...].
* as the last line of #drawWorld2:... add
	self rearmOneShot.
Thus the new version will have to complete in order to be called again.
If it raises an error it'll just fall back to the old version and needs
to be manually reinstanted. I find this trick to be tremendously useful
when you have to work on those kind of problems.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Jim Benson
> Sent: Wednesday, May 01, 2002 9:16 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: rounded corners (was: Re: straw-man 3.2 default 
> preferences)
> 
> 
> Andreas,
> 
> >
> > #2: The top-down drawing method of the world is broken. It 
> has tons of
> > overdraw which could be completely eliminated.
> >
> 
> Is there some straightforward way to do this, or is it 
> tangled everywhere in
> the code? As a ballpark estimate, what type of speed increase 
> do you think
> would come out of working in this area?
> 
> Jim
> 
> 
> 
> 
> 
>