Be more restrictive about forcing relayout of children for pagination.

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
Committed: https://crrev.com/6f896bf597e1709b0c6dfc589c0cd7493a5acc4a
Cr-Commit-Position: refs/heads/master@{#428626}

[mstensho (USE GERRIT), 2016-10-28 13:23:22]

The CQ bit was checked by mstensho@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 13:23:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-28 15:07:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 15:07:26]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[mstensho (USE GERRIT), 2016-10-28 19:49:55]

The CQ bit was checked by mstensho@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 19:50:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mstensho (USE GERRIT), 2016-10-28 19:57:23]

Description was changed from

==========
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
almost 1000 times faster (from 7.866 runs/s to 7418 runs/s when tested
locally).

Store the amount of remaining space in the first fragmentainer instead.  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 those 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 they will remain at the exact same places.

Store this information using updateFragmentationInfoForChild().

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.

BUG=487026
==========

to

==========
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).

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().

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
==========

[mstensho (USE GERRIT), 2016-10-28 20:02:06]

Description was changed from

==========
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).

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().

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
==========

to

==========
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
==========

[mstensho (USE GERRIT), 2016-10-28 21:07:48]

mstensho@opera.com changed reviewers:
+ eae@chromium.org

[commit-bot: I haz the power, 2016-10-28 21:24:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 21:24:21]

Dry run: This issue passed the CQ dry run.

[eae, 2016-10-30 12:35:24]

Wow, this is amazing!

LGTM

[eae, 2016-10-30 12:35:31]

The CQ bit was checked by eae@chromium.org

[commit-bot: I haz the power, 2016-10-30 12:35:35]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-30 14:04:28]

Description was changed from

==========
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
==========

to

==========
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
==========

[commit-bot: I haz the power, 2016-10-30 14:04:29]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-10-30 14:06:40]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/6f896bf597e1709b0c6dfc589c0cd7493a5acc4a
Cr-Commit-Position: refs/heads/master@{#428626}
==========

[commit-bot: I haz the power, 2016-10-30 14:06:41]

Patchset 3 (id:??) landed as
https://crrev.com/6f896bf597e1709b0c6dfc589c0cd7493a5acc4a
Cr-Commit-Position: refs/heads/master@{#428626}