Rework frame invalidation during reflow

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
13 years ago
9 years ago

People

(Reporter: roc, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor])

See https://bugzilla.mozilla.org/show_bug.cgi?id=323291#c5

Frame invalidation during reflow is a mess. It's not clear who is responsible for repainting what. Furthermore, it is probably a source of performance problems when we invalidate frames individually.
I think the general invalidation strategy should be something like this:

-- frames start with zero size
-- when a frame is moved during reflow (the only time it can be moved, except during scrolling), invalidate its entire old and new overflow areas and need not bother doing any invalidations for its descendants
-- when a frame changes size during reflow (the only time it can be resized), but it didn't move, then invalidate the area that is the difference between its old and new size ... unless the frame or its styles indicate that the entire frame must be repainted on a size change (see nsFrame::CheckInvalidateSizeChange), in which case we do that
-- when a frame is removed from the frame tree, we invalidate its area

All other invalidation is caused by style changes or intrinsic state changes and can continue to be handled as we do today.

I'll wait till the reflow branch lands to see what the best way is to realize this.
Whiteboard: [reflow-refactor]
*** Bug 323574 has been marked as a duplicate of this bug. ***
We should use display-list-based invalidation instead (bug 539356).
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
Assignee: roc → nobody
You need to log in before you can comment on or make changes to this bug.