OpacityLayer peephole optimization does not optimize multiple non-overlapping children

[flar]

The peephole optimization that will allow an OpacityLayer to hand off its opacity value to its children to avoid a saveLayer will only currently apply its optimization to a single child as it is initially implemented in flutter/engine#29775.

With further processing, the children could be checked for their paint_bounds() overlapping and multiple children could all inherit the opacity value, increasing the number of cases optimized.

[JsouLiang]

the children could be checked for their paint_bounds() overlapping and multiple children

Could we use RTree to check if the children is intersection?
cc @flar

[flar]

This optimization was actually implemented before flutter/engine#29775 was even landed.

[flar]

the children could be checked for their paint_bounds() overlapping and multiple children

Could we use RTree to check if the children is intersection? cc @flar

An RTree can potentially produce a more authoritative answer at a greater cost. The question is how much better is its answer compared to the cost of using it on every container's individual children?

[JsouLiang]

Should we support this : https://github.com/flutter/engine/blob/main/flow/layers/container_layer.cc#L156
cc @flar

[flar]

Should we support this : https://github.com/flutter/engine/blob/main/flow/layers/container_layer.cc#L156 cc @flar

That is another possibility. Since we are going to need to deal with RTree sooner or later to support platform embedders that rely on RTree for event distribution, we have to do some research to figure out which of these mechanisms can support what we need. The simple "while new children don't intersect previous bounds" test could probably be done with minimal work using the existing BoundsAccumulator work in the BoundsCalculator, but that isn't integrated with the construction and DL objects must be immutable after construction.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.