Currently we determine which layers and pictures should be cached during the Preroll pass. That is probably a good time to evaluate which layers are good candidates.

Unfortunately, we also go ahead and directly populate the caches with those layers and pictures right from the code that marks them as a cache candidate during the Preroll pass.

This approach has multiple problems:

• If a parent and a child both think they want to be cached, then we end up caching them both even though the caching of the parent supersedes the caching of the child
• Each frame only gets to populate 3 items and those are chosen on a first-come, first-served basis rather than on need or benefit (discussed in Consider allowing "complex" pictures to avoid the per frame raster cache limit #87834, but the problem is larger than a single exception in the metrics - really the decision needs to be made with scene-wide considerations)
• If there are entries in the cache that won't be reused then we allocate the new cache images before we get rid of the old ones
• Without a global assessment of caching needs, it would be hard to implement packing their images together into a single texture as discussed in RasterCache could reuse or combine (i.e. atlas) SkSurfaces during composited scale animations #83189
• A separate pass could combine both information gathered during Preroll as well as information gathered during the DRM DiffContext pass and combine those 2 separate sources into a more informed list of cache candidates

With respect to the metrics used to choose which to populate, our current hard limit of 3 items fails in a number of ways:

• What is the expense of populating multiple entries in a single frame, is it the number of new cache entries created? Is it their complexity? Is it a combination of the 2?
• Many of the issues mentioned in the previous list further complicate the effectiveness of this metric - including caching both a parent and a child on the same frame thus wasting a cache entry
• Caching the contents that would normally be rendered in a save layer doesn't really cost anything extra because if we don't cache the content, then the Paint method will just use a saveLayer which is like a cache entry that doesn't persist across frames