In Flutter, Image objects are underpinned by SkImages, which are immutable refcounted objects. An SkImage cannot release its underlying image data until its refcount drops to zero. The same is true for Paths, Vertices, and other things we draw into Pictures, but it's especially important for Images since they tend to use more memory.

We draw SkImages into SkPictures, so whatever picture we draw an image into also has to have its refcount go to zero to release the image memory.

SkPictures end up being held by Picture objects in Dart, which in turn are held by Layer objects. They are also held internally by the engine by PictureLayer objects, which do not have an exact Dart peer but are indirectly held by other Dart peer Layers (which hold on to EngineLayer objects eventually). Layers have a somewhat ambiguous ownership model - they are owned potentially by other layers or by RenderObjects. RenderObjects have no disposal method.

In an ideal world, we would have a proper lifecycle established for RenderObjects, Layers, EngineLayers, Pictures, and Images. Unfortunately, doing this will require a number of breaking changes.

If we could figure out all the breakages necessary for this and create some clearer ownership models, we could have a better Image API (and generally allow people to reason a bit more about when potentially expensive resources they've drawn into a Picture can be freed).

I believe this is an API break because application code would have to update the way it interacts with RenderObjects and/or Layers.