Picture objects retain anything drawn into them. This can be troubling when they retain Image or other large chunks of memory.

Unfortunately, today, Picture objects have no lifecycle. They have a dispose method that the framework never calls. They are mainly held by Layer objects in the framework, which also have no clearly defined lifecycle. They are passed back into the engine side and passed around as shared pointers.

Generally speaking, it requires a garbage collection to figure out when a picture object can be reclaimed. However, this can be expensive and may not happen at an ideal time. Even scheduling collections more aggressively when we believe we're done with an image is imperfect, since it can schedule expensive collections too often.

It would be better if we disposed picture objects at some point where we could be convinced we are done with them, which would allow us to release the native pointers into Skia even if a GC has not occurred.

The main challenge with this is around Layer objects. Layers have no clear owner and get passed around. Additionally, we have three parallel layer trees:

• flutter::Layer objects that are meant to be used on the raster task runner by the rasterizer.
• flutter::EngineLayer objects which are native peers to Dart EngineLayer objects and reference flutter::Layer objects.
• Layer objects in the Flutter framework, some of which hold EngineLayer objects.

~~On the engine side, we should make sure that any Dart UI C++ backing objects drop native references at appropriate times. The only obvious miss right now is SceneBuilder::build, which does not let go of the layer_stack_ ivar, and Scene::dispose (which is less serious because typically the scene gets its layer pointer stolen away when it is rendered). ~~

The real issue here is to make sure that the framework does not hold references to flutter::Layer objects any longer than necessary, to avoid cleaning up the layer tree via GC.

/cc @yjbanov because we've also talked about how this could help on Safari.