323576 - Rework frame invalidation during reflow

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

*** Bug 323574 has been marked as a duplicate of this bug. ***

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should use display-list-based invalidation instead (bug 539356).