Introduce memory cap for so that scrolling past many images does not spike memory in an unbounded fashion

[kf6gpe]

The customer: dream (g3) team would appreciate help with measuring and limiting memory spikiness when dealing with images. Memory consumption in steady state is okay-ish, but during intense image loading/unloading it can grow unbounded. For their applications it's generally good to have some sort of memory cap that the engine may not exceed, and expensive allocations should not run in parallel.

See https://buganizer.corp.google.com/issues/144232910#comment94 and other comments for more info.

cc @cbracken @chinmaygarde for assignment.

[Hixie]

(Removing from critical since this is not going to be a blocker but would be a good thing for us to improve medium term.)

[dnfield]

I think this may be a duplicate of #50024

I'm not convinced that a memory cap is the right way to go. The main question is what to do when you hit that cap, and there's no great answer for that.

The customer should be in a better state if they're taking advantage of some recent changes to image decoding for the "live image cache" and avoiding decoding while scrolling fast (#51485 and #49389).

I'll comment on the internal bug as well.

[dnfield]

We further discussed things at #48305 (comment) - and broke that into several more issues. I'm going to close this one since it is less specific than the newly filed issues.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.