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
danielv@netvision.net.il wrote...
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?
The problem of damage from world Halos was discussed in September, and I fixed it completely by making #changed only invalidate the submorphs of a halo. This was then broken by the code to which you refer.
Andreas is out of town for the holidays. We discussed this problem, and he said this was an early part of the optimizations needed for the new alignment mechanism. I tried the obvious revert and it produced undesirable side-effects. As soon as we have a chance to compare notes, we'll put out a fix.
- Dan
danielv@netvision.net.il wrote:
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"
I put up the menu for this morph and noticed that menu lines with the newly introduced checkbox in the menus blinked too.
Karl
squeak-dev@lists.squeakfoundation.org