RIP

A bit of an improvement in build time though: https://flutter-flutter-perf.skia.org/e/?begin=1654519388&end=1654557788&keys=X9a7c2124d9fcf89df41efc260e9a0129&num_commits=50&request_type=1&xbaroffset=29332

It seems like we might not be doing the peephole optimization if we don't end up compositing the opacity layer, though @flar would be the expert here

DLs only currently check if they can accept an external opacity. They also check each internal saveLayer if it could also accept one - as an implementation detail for detecting the external acceptance criteria - but they don't check to see if they are themselves the source of an "opacity saveLayer".

It looks like they do check for an "opacity saveLayer", but it looks like it doesn't trigger for some reason:

https://github.com/flutter/engine/blob/02590c79ad4c53b4d939fb0f9a54839cb675d4d0/display_list/display_list_canvas_dispatcher.cc#L60

It looks like the grid of opacity benchmark is failing to distribute opacity because the conservative tests in the saveLayer dispatch method linked above will refuse to propagate the opacity if a bounds is supplied for the saveLayer. This is "safe", but unnecessary if the bounds for the saveLayer are large enough to hold all of the children. For OpacityLayer, the bounds of the saveLayer are known to contain all of the children because the bounds are provided by child_layer_bounds, so it can more aggressively apply this optimization. For DL, unfortunately, the bounds are not known while the DL is being constructed so this information cannot be used to gate the optimization.

Other peephole benchmarks that try to apply opacity to a number of overlapping children take advantage of the overlap testing inside ContainerLayer::PrerollChildren which is also missing from DL.

A quick test of commenting out the bounds check inside the saveLayer dispatch method above shows that performance not only improves, it beats the previous benchmark results by a wide margin.

In order to enable equal conditions for the saveLayer dispatch method compared to the OpacityLayer conditions we will need to fix the following issues (the RTree stuff will enable better overlap testing, but a simple overlap condition similar to what is done in the PrerollChildren code can be done by only fixing the first 2 issues):

• Collapse bounds calculations into DisplayListBuilder #100172
• OpacityLayer peephole optimization does not optimize multiple non-overlapping children #93899
• DisplayList has no proactive culling as was available in SkPicture #92740