Boris Zbarsky wrote:
What's the contract for invalidating during reflow? nsIFrame seems to be silent on the matter... In particular, who is responsible for calling Invalidate() on which rects in the following situations:
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. 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.
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.
3) Both
As #2.
The options here are "the frame affected" and "the parent of the affected frame (possibly via a proxy such as nsLineBox)", I think. Are there other options?
I'm not sure what else is actually done in the code. It's quite likely that the above policy isn't always followed. However, I think it's an OK policy. It is important that when a frame grows we don't invalidate its whole area, otherwise we repeatedly invalidate top-level block frames during page load incremental reflow, and I believe Tp would suffer. We could shift responsibility for partial invalidates of resized frames to the resized frame, which would make the code easier to understand, but maybe cause extra redundant calls to Invalidate (because the parent can often coalesce invalidates and/or just invalidate everything when that is inevitable).
Are there other cases of reflow-related invalidates needing to happen?
I *think* that if the frame's size and position don't change, then reflow never needs to invalidate it. That would seem logical anyway...
How is this related to the changehint for various attributes? Should the hint for cases that require reflow be just ReflowFrame, or include a paint hint?
The former. Right now we always fully repaint but that is wasteful. If an attribute only affects geometry and not (directly) rendering, then it should not need the paint hint.
If the latter, is that paint expected to happen before or after the reflow?
Given the above, it shouldn't matter. Reflow guarantees that the difference between the old area (O) and the new area (N) is invalidated. At the risk of horrific abuse of notation, "O \union (O ^ N) = N \union (O ^ N)", so whether you invalidate the old area or the new area, enough is invalidated.
Once dbaron has chimed in we should write this down somewhere, probably in the reflow document.
Rob
_______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
