[css-flexbox] Don't over-invalidate flex items

[css-flexbox] Don't over-invalidate flex items

dirtyForLayoutFromPercentageHeightDescendants invalidates too much. We already
have code to handle this case, so remove this call. We did have a bug in
that code though -- we do need to force layout on flex items even if did not
lay them out already: such percentages are only resolvable if the flexbox has
a definite height. However, whether the flexbox height is definite may have
changed since the last layout. So, we need to relayout in either case.

The similar code in applyStretchAlignment does not have this issue because
percentages in the cross axis can be resolved independent of whether the
flexbox height itself is definite.

This is covered by an existing test; the call to
dirtyForLayoutFromPercentageHeightDescendants was previously covering this case
but is slower.

This caused a massive performance regression (many minutes to lay out a
flexbox-based website instead of a few seconds).

TEST=css3/flexbox/definite-cross-sizes.html
BUG=595361, 617792
R=dgrogan@chromium.org,eae@chromium.org

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

Committed: https://chromium.googlesource.com/chromium/src/+/291a41e2a82664720953ddc7bc6b3f4e86f07b83

[cbiesinger, 2016-07-08 16:55:36]

Description was changed from

==========
[css-flexbox] Don't over-invalidate flex items

dirtyForLayoutFromPercentageHeightDescendants invalidates too much. We already
have code to handle this case, so remove this call. We did have a bug in
that code though -- we do need to force layout on flex items even if did not
lay them out already: such percentages are only resolvable if the flexbox has
a definite height. However, whether the flexbox height is definite may have
changed since the last layout. So, we need to relayout in either case.

The similar code in applyStretchAlignment does not have this issue because
percentages in the cross axis can be resolved independent of whether the
flexbox height itself is definite.

This is covered by an existing test; the call to
dirtyForLayoutFromPercentageHeightDescendants was previously covering this case
but is slower.

This caused a massive performance regression (many minutes to lay out a
flexbox-based website instead of a few seconds).

TEST=css3/flexbox/definite-cross-sizes.html
BUG=595361,617792
R=dgrogan@chromium.org,eae@chromium.org

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

to

==========
[css-flexbox] Don't over-invalidate flex items

dirtyForLayoutFromPercentageHeightDescendants invalidates too much. We already
have code to handle this case, so remove this call. We did have a bug in
that code though -- we do need to force layout on flex items even if did not
lay them out already: such percentages are only resolvable if the flexbox has
a definite height. However, whether the flexbox height is definite may have
changed since the last layout. So, we need to relayout in either case.

The similar code in applyStretchAlignment does not have this issue because
percentages in the cross axis can be resolved independent of whether the
flexbox height itself is definite.

This is covered by an existing test; the call to
dirtyForLayoutFromPercentageHeightDescendants was previously covering this case
but is slower.

This caused a massive performance regression (many minutes to lay out a
flexbox-based website instead of a few seconds).

TEST=css3/flexbox/definite-cross-sizes.html
BUG=595361,617792
R=dgrogan@chromium.org,eae@chromium.org

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

Committed:
https://chromium.googlesource.com/chromium/src/+/291a41e2a82664720953ddc7bc6b...
==========

[cbiesinger, 2016-07-08 16:55:37]

Committed patchset #1 (id:1) manually as
291a41e2a82664720953ddc7bc6b3f4e86f07b83.