Gold has detected about 14 untriaged digest(s) on patchset 1.
View them at https://flutter-gold.skia.org/cl/github/83145

Gold has detected about 21 new digest(s) on patchset 1.
View them at https://flutter-gold.skia.org/cl/github/83145

FYI, this was reverted in #84187 because of Google bug b/190453741

I wonder if this is raster cache related. Maybe we could work around it by pushing some other layer in place of the existing opacity layer - but at least we have benchmarks to check on!

I wonder if this is raster cache related. Maybe we could work around it by pushing some other layer in place of the existing opacity layer - but at least we have benchmarks to check on!

The layer coming and going basically causes a side effect that the composition of the pictures around the child are disrupted. When the layer is pushed then any Picture currently being built is ended, the children are rendered into their own picture and when they return that Picture is ended and a new one will be created for any content that follows.

When the layer is not pushed, then the preceding children will share a Picture with the children of the animated widget which will also share a Picture with the following children.

I think what we need to ensure is that the previous, descendant, and following content remain isolated regardless of the alpha. Pushing the opacity layer will always ensure this, but it can be managed simply by ensuring that the pictures are broken before and after the children are painted.

It would be even better if this whole sub-tree were treated as a RepaintBoundary - that would make sure that there is no sharing of Picture objects across this widget and also would prevent the changing opacity from causing adjacent children to repaint on either side.