The fix for #120455, introduced in flutter/engine#39690 caused a shift in some of the memory benchmarks that measure cache usage from picture caching to layer caching.

This wasn't predicted, but is to be expected due to the nature of the fix. Without the fix we get noticeable flashing so reverting the fix isn't appropriate and the memory merely shifted rather than increased and the time metrics didn't flag a regression. So, there is no big practical measurable regression from this issue.

Picture metrics decreasing:
https://flutter-flutter-perf.skia.org/e/?begin=1676609568&end=1676681408&keys=X91060e41b7e82bf83ef90d3fe5f84a35&num_commits=50&request_type=1&xbaroffset=33419

Layer metrics increasing:
https://flutter-flutter-perf.skia.org/e/?begin=1676609568&end=1676681408&keys=X854efad91537cb086050237bfad88626&num_commits=50&request_type=1&xbaroffset=33419

The root cause is that picture layers used to declare themselves as able to inherit opacity when they became eligible to cache. The problem is that "eligible to cache" doesn't mean that they will be successful. In particular, we only allow 3 pictures to cache per frame so if there were more than 3 children than all of them might say they can inherit opacity, but only 3 would be telling the truth. The fix requires the children to wait until they successfully cache themselves before they declare that they can inherit opacity. The problem is that if the parent is caching the children then it will tell the children not to cache themselves. This policy prevents double-caching where the parent is caching the children who are also caching themselves. Unfortunately, since the children can never cache themselves, they also never declare that they can inherit opacity. Thus, a chicken and egg situation.

The fix will require some careful decisions about the eligibility and potential eligibility of the children to cache themselves and thus inherit opacity.