The Flutter engine will attempt to estimate the "cost" of the pictures that it renders. When this cost exceeds a threshold and the picture itself is stable, the engine will create a "raster cache" entry for that picture. The raster cache essentially replace the display/canvas operations with a texture containing the rasterized elements which will be reused on subsequent frames. The idea being that this will be cheaper and lead to more performant applications.

There are a few serious problems with the current raster cache complexity based scoring:

• Failure to measure tradeoffs

The benchmarking infrastructure was designed to capture the cost of the cache removing the raster ops on the devices CPU. It did not measure the potentially increased GPU load from texture sampling/loading from video memory. From some local investigations, texture sampling can be multiple times slower than executing the original shaders.

There is also an additional memory cost to holding these raster images. They are only stored in native resolution and can add severals 10s of MB to video memory usages.

• Unpredictable performance

Sometimes developers will inadvertantly create extremely expensive pictures, perhaps by doing something like emulating a paint application with stacked drawing + clears. The performance of this application will likely ping pong between smooth (as hundreds of draw ops are replaced with a texture) to janky once a new drawing operation is appended. This performance is likely to be less intuitive than if we were consistently slow. At least then they might look to developing their own caching strategy that didn't pingpong.

• Unmaintainable herustics

The herustics used to populate the complexity scoring mechanism were developed by a never productionized one time script. From investigation, we know that several of these metrics are likely wrong. For example, there is no advantage to replacing large text blobs with a raster cache entry, as the text blobs are already drawn from sampled textures.

Because of these issues, we've previously decided not to port the raster cache to Impeller. This issue considers the case of also removing this from the Skia backend.

Experimental results

On Friday July 21, I disabled the picture complexity based raster cache heuristics in the engine. There were really only two benchmark changes of note:

1. The complex layout scroll perf 90% time regressed by 2.5 MS

https://flutter-flutter-perf.skia.org/e/?begin=1689935934&end=1690044312&keys=X837961e90618ea0b4da8b84f85cdcb0a&selected=commit%3D35908%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DSM-A025V%252Cdevice_version%253Dnone%252Chost_type%253Dlinux%252Csub_result%253D90th_percentile_frame_rasterizer_time_millis%252Ctest%253Dcomplex_layout_scroll_perf__timeline_summary%252C&xbaroffset=35908

2. The worst frame time of the textfield perf microbenchmark improved by 325ms

https://flutter-flutter-perf.skia.org/e/?queries=test%3Dfullscreen_textfield_perf&selected=commit%3D35908%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DMoto_G__4_%252Cdevice_version%253Dnone%252Chost_type%253Dlinux%252Csub_result%253D99th_percentile_frame_rasterizer_time_millis%252Ctest%253Dfullscreen_textfield_perf%252C