Be more restrictive about forcing relayout of children for pagination.
Avoid full subtree re-layouts that could especially occur in tables. This could
slow down printing and multicol by a lot.
This change makes PerformanceTests/Layout/multicol/deeply-nested-tables.html
about 1300 times faster (from 5.1 runs/s to 6813 runs/s when tested
locally). The test in bug 487026 will now show print preview instantly, rather
than taking a couple of minutes to finish.
Store the amount of space used (including the trailing strut) before the first
break (if any) instead of the offset from the top of the first fragmentainer.
We'll use this information in markChildForPaginationRelayoutIfNeeded() to
determine if we really need to force re-layout of some child. We really only
need to force re-layout of a child if there's a chance that it needs to
recalculate its pagination struts. It won't need to recalculate anything if we
know that there were no fragmentainer breaks AND that there won't be any if
we re-lay out. Even if there ARE fragmentainer breaks in there, we can still
skip layout if we know that the breaks will remain at the exact same locations
relative to the child. Store this information after layout by calling
updateFragmentationInfoForChild(). We need to include the overflow portion
after the bottom border edge of the child, since overflow also gets fragmented.
The old implementation of markChildForPaginationRelayoutIfNeeded() re-laid out
everything as long as LayoutState's pageLogicalHeightChanged() was true.
However, this flag is only set when entering layout of some fragmentation
context. Some objects, such as tables, requires multi-pass layout. If the flag
was true the first time the object was laid out, it's going to be true in all
subsequent re-layouts as well, potentially resulting in numerous deep layouts.
BUG=487026
Review-Url: https://codereview.chromium.org/2462643002
Cr-Commit-Position: refs/heads/master@{#428626}
11 files changed
