Avoid unnecessary cell layout on nested percent height tables

Avoid unnecessary cell layout on nested percent height tables

In the test, the nested percent height tables mean that each cell will get at
least three layouts (LayoutTableRow::layout(),calcRowLogicalHeight(), layoutRows())
during the layout of the section - and this cascades down the tree with the lowest
children getting hundreds of repeated layouts.

This inefficiency has always been there, we've just introduced it for the
percent height situation with crrev.com/2441373002.

To avoid this don't bother computing the height of the section based on row sizes (calcRowLogicalHeight()),
unless the section itself needed a layout - the previously calculated value will do.

The only complication this introduces is: any extra logical height from the
table that we previously discarded when distributing to the rows we will now
try to distribute again. This can change the size of the section and cause extra
paints.

BUG=687061
Review-Url: https://codereview.chromium.org/2670603002
Cr-Commit-Position: refs/heads/master@{#449101}
(cherry picked from commit d3ceb0147ad9f4d4a9b41cea0362d6221cb72302)

Review-Url: https://codereview.chromium.org/2696653003 .
Cr-Commit-Position: refs/branch-heads/2924@{#912}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}
Committed: https://chromium.googlesource.com/chromium/src/+/f799408c02bfd85d001b2318cf0af0f98d2146ba

[rhogan, 2017-02-13 20:32:31]

Description was changed from

==========
Avoid unnecessary cell layout on nested percent height tables

In the test, the nested percent height tables mean that each cell will get at
least three layouts (LayoutTableRow::layout(),calcRowLogicalHeight(),
layoutRows())
during the layout of the section - and this cascades down the tree with the
lowest
children getting hundreds of repeated layouts.

This inefficiency has always been there, we've just introduced it for the
percent height situation with crrev.com/2441373002.

To avoid this don't bother computing the height of the section based on row
sizes (calcRowLogicalHeight()),
unless the section itself needed a layout - the previously calculated value will
do.

The only complication this introduces is: any extra logical height from the
table that we previously discarded when distributing to the rows we will now
try to distribute again. This can change the size of the section and cause extra
paints.

BUG=687061

Review-Url: https://codereview.chromium.org/2670603002
Cr-Commit-Position: refs/heads/master@{#449101}
(cherry picked from commit d3ceb0147ad9f4d4a9b41cea0362d6221cb72302)
==========

to

==========
Avoid unnecessary cell layout on nested percent height tables

In the test, the nested percent height tables mean that each cell will get at
least three layouts (LayoutTableRow::layout(),calcRowLogicalHeight(),
layoutRows())
during the layout of the section - and this cascades down the tree with the
lowest
children getting hundreds of repeated layouts.

This inefficiency has always been there, we've just introduced it for the
percent height situation with crrev.com/2441373002.

To avoid this don't bother computing the height of the section based on row
sizes (calcRowLogicalHeight()),
unless the section itself needed a layout - the previously calculated value will
do.

The only complication this introduces is: any extra logical height from the
table that we previously discarded when distributing to the rows we will now
try to distribute again. This can change the size of the section and cause extra
paints.

BUG=687061

Review-Url: https://codereview.chromium.org/2670603002
Cr-Commit-Position: refs/heads/master@{#449101}
(cherry picked from commit d3ceb0147ad9f4d4a9b41cea0362d6221cb72302)

Review-Url: https://codereview.chromium.org/2696653003 .
Cr-Commit-Position: refs/branch-heads/2924@{#912}
Cr-Branched-From:
3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}
Committed:
https://chromium.googlesource.com/chromium/src/+/f799408c02bfd85d001b2318cf0a...
==========

[rhogan, 2017-02-13 20:32:33]

Committed patchset #1 (id:1) manually as
f799408c02bfd85d001b2318cf0af0f98d2146ba.