OpacityLayer will attempt to cache its children and render them with an alpha value as it renders from the cache. This is around the same speed as doing a saveLayer with the alpha value, which is the default fallback implementation, but it can be much faster if the children are stable and it can reuse their cache entry from the previous frame.

If the children are not stable, it should be similar in performance to saveLayer anyway, but there are a few drawbacks to our layer raster cache that make it less than ideal:

• If the children are unstable then on each frame we will cache the new children, render them with alpha from the cache, and then only delete the old cache entry at the end of the frame - thus we have 2x the memory for the children for the bulk of the work on every frame (the old cache entry and the new one). Between frame renderings there is only a single cache entry, though.
• If we reimplement the cache to make cache eviction and populate decisions in a single pass rather than split between Preroll (for populating) and a final cleanup pass (for evictions), then we would avoid having both cache items around during the rendering pass
• If we did the cache evict/populate in a single pass, we might find that we can reuse the cache entry from the previous children, but by this point the savings over a saveLayer may be minimal (would need to test to be sure).

The peephole optimizations being added in flutter/engine#29775 may remove the need for caching or saveLayers, provided the conditions are met for the peephole validation.