Sorry, forgot to mention this -
BouncingAtomsMorph has an optimization that masks the difference. I
guess it's pretty old, being superflous even with the current methods.
Change to false:

invalidRect: damageRect from: aMorph
...
	quickRedraw _ true.  "false gives the original invalidRect: behavior"


BTW, I noticed this has interesting behavior with the Halos, too. Try to
guess what it is before you try it...

Andreas - I noticed that world halos always invalidate the world, and
traced this to CS 2957. One of the offenders is -
Morph>>addMorph:inFrontOf:
...
	self isInWorld ifTrue:[self invalidRect: newMorph fullBounds from:
newMorph].
removing that line fixed adding the halos, but removing them still has
the undesired effect. Is this simply not uptodate or something? seems
superflous because any morph added should know to invalidate itself, no?

Doug Way <dway at riskmetrics.com> wrote:
> 
> danielv at netvision.net.il wrote:
> > 
> > "Change Set:            AlternativeDamageRecord
> > Date:                   23 December 2000
> > Author:                 Daniel Vainsencher
> > 
> > Uses alternative heuristic for recording damage -
> > for any new damage (that isn't completely contained by the old damage),
> > compare the costs of drawing it and each existing rect to the cost of
> > drawing them merged. If a merge with any is cheaper, merge them, and run
> > the same test on the new area. The approximation of costs use shoud
> > handle many cases well that previously required special attention. Test
> > with bouncing atoms, see them cluster."!
> 
> Sounds like a good idea.  But I tried filing this into a 2.9alpha-3144
> image (with debugShowDamage turned on), and the entire bouncing atoms
> morph always seemed to blink... I didn't see any clustering, even if I
> played around with resizing the morph.
> 
> - Doug Way
>   dway at riskmetrics.com