Interesting!

I did a quick and dirty hack in LayoutNGMixin::CachedLayoutResult() that checks if inline size would change, and then return the cached layout result if it wouldn't. 95% speedup in perf_tests/layout/many-block-children-fixed-inline-size.html

For this to work correctly, I think we need to make the other size fields in NGConstraintSpace apart from available_size_ optional (and if they're not set, return available_size_ for those things). Because, if something needs to set a specific percentage resolution size, for instance, I think we need to descend into children - thanks to quirks and table layout.

Worth exploring?

We can deal with the percentage size issue by checking HasPercentageHeightDescendants, I think?

Oh, I thought HasPercentageHeightDescendants() was a legacy mechanism that isn't / shouldn't be / cannot be used in NG, but maybe I'm wrong.

I had to make it work in NG: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/ng/ng_length_utils.cc?type=cs&q=ComputePercentageL&sq=package:chromium&g=0&l=954

Oh, I see. Maybe that will work, then.

Next problem:
What about initial containing block size? We can't easily tell if we have orthogonal flow roots among the children. But we really don't want to re-lay out everything every time the window is resized.

Oh, that's a great point :(

Maybe can use this list here in some way:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/local_frame_view.cc?q=layoutorth&sq=package:chromium&g=0&l=1697

Or store a bit in NGLayoutResult whether there are descendants that establish orthogonal flow roots or not.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af

commit 427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af
Author: Morten Stenshorne <mstensho@chromium.org>
Date: Sat Nov 03 09:31:43 2018

[LayoutNG] Use cached fragment if size won't change.

Available size may change from one layout pass to another, but that
doesn't have to mean that we need to re-lay out a child. If we can be
sure that its size will remain the same, and that if it will keep the
same size, that won't affect any descendants, we can skip layout and
return the cached fragment.

We cannot ignore initial containing block size changes if there are
orthogonal flow root children, so keep track of that.

Makes perf_tests/layout/many-block-children-fixed-inline-size.html
about 3 times faster.

Update expectations for one invalidation test. The test has some
fixed-width descendants, so when only the window width changes,
there's less work to do, than before.

Update one unit test, and expand it a bit, to provide a case where we
actually still do need layout.

Bug: 897450
Change-Id: I063f650110d5a488de430b938b3d46e713a1433e
Reviewed-on: https://chromium-review.googlesource.com/c/1297367
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605168}
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-margin-bottom.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-margin-left.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-margin-right.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-margin-top.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-padding-bottom.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-padding-left.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-padding-right.html
[add] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/external/wpt/css/CSS2/normal-flow/containing-block-percent-padding-top.html
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/WebKit/LayoutTests/flag-specific/enable-blink-features=LayoutNG/paint/invalidation/window-resize/window-resize-centered-inline-under-fixed-pos-expected.txt
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/layout_block_flow.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/layout_block_flow.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/geometry/ng_physical_size.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/layout_ng_mixin.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_block_layout_algorithm.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_block_layout_algorithm_test.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_constraint_space.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_constraint_space.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_container_fragment_builder.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_container_fragment_builder.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_layout_input_node.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_layout_result.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_layout_result.h
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_length_utils.cc
[modify] https://crrev.com/427a8f5dcf2b4376f18d5f9cdd0e0bf7521a69af/third_party/blink/renderer/core/layout/ng/ng_length_utils.h

https://chromium-review.googlesource.com/c/1407086 also improves on this.

Should we still keep this bug open?