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@riskmetrics.com wrote:

danielv@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@riskmetrics.com