This is wretchedly unclear and it's about time we documented it :-).
I wasn't asking just because I was bored... ;)
1) Frame is resized (eg "width" attr of image changed)
The parent frame is responsible for invalidating the difference between the old and new rects.
OK. We could use a nice function on nsRect to compute the disjunction of two rects (A \union B) - (A \intersect B) for use here, no?
Come to think of it, in my example the resized frame would need to invalidate all of itself (since it would be rescaling the image)... Your example of <body> growing during pageload is better.
If the resized frame needs to repaint more of its area (e.g., if it has borders) then it is responsible for invalidating that. See ns[HTML]ContainerFrame::CheckInvalidateSizeChange.
OK. We may want to optimize that a bit at some point, maybe.... (we may not need to repaint the whole rect just to move the bottom/right borders about...)
2) Frame is repositioned (eg "align" attr of <legend> changed)
The parent frame is responsible for invalidating the union of the old and new areas.
OK. Makes sense.
3) Both
As #2.
OK.
I'm not sure what else is actually done in the code.
Lol. I don't think we care, since I doubt it's too consistent.
It's quite likely that the above policy isn't always followed.
You think? ;)
It is important that when a frame grows we don't invalidate its whole area
Agreed.
but maybe cause extra redundant calls to Invalidate
How expensive is Invalidate()? It just coalesces rects or appends a rect to a region, right? It may be worth paying the price of extra Invalidate() calls for clarity if Invalidate() is very fast...
(because the parent can often coalesce invalidates and/or just invalidate everything when that is inevitable).
And there is that.
Once dbaron has chimed in we should write this down somewhere, probably in the reflow document.
I'd vote we document at least something about this on the nsIFrame methods that resize/reposition the frame. If nothing else, add a pointer to the appropriate reflow document section there.
-Boris _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
