You do not have permission to edit this page, for the following reasons:
This is perhaps out of date and in need of updating, especially once views are removed and in light of dbaron's reflow branch.
Currently our rules for invalidation are quite inconsistent, in particular the rules for who is responsible for invalidating what during reflow.
Currently, I believe the rules include:
We're inconsistent about whether 'bounds' means the actual frame bounds or the overflowArea.
Sometimes we suppress invalidation, e.g. during initial reflow, for performance reasons. This needs to be systematized.
Moving a view always repaints the union of the old and new view areas (which is the union of all frames contained by the view), and resizing a view always repaints the difference. I think we rely on this in some places to avoid frame invalidation. But it's not very efficient. For example if a frame has overflowing absolute frames that move around, then the frame's view will resize and we'll invalidate large horizontal and vertical strips. Graphically:
+-------+ ********* |Frame F| ********* | | ********* | | +--+ +--+ | | |A | |A'| | | +--+ +--+ | | ********* +-------+ *********
If A is an absolute child of F and it moves from A to A', then we'll repaint the area marked with asterisks when we only need to repaint the area covered by A and A'.
One thing we need to be careful about is that currently nsIFrame::Invalidate just issues an UpdateView against the nearest view containing the frame. The invalidation area is intersected with the view's bounds. So for example a frame with a view cannot invalidate an area bigger than its view without doing something tricky. For the rules below to work, we need to change this so nsIFrame::Invalidate will invalidate pixels even if they lie outside the frame's view. Imagine in the scenario above that frame F's reflow of its absolute children wants to perform the invalidation of A and A'. This will happen *before* F's view is resized, so currently the invalidation of A' would be lost.
Here are some rules that I think would be easy to maintain and also efficient:
(Can't we suppress when unconstrained reflows are issued on child frames, as there is a promise that the frames will be reflown with a constrained size? Bernd) Gecko:Roc: I don't think so because the constrained-size reflow will only invalidate what's changed since the last reflow.