-
-
Notifications
You must be signed in to change notification settings - Fork 868
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Excessive GPU Memory Usage: Old Tile Images Are Never Reclaimed, App Death Ensues #2006
Comments
I performed a sequential test. First, with Skia, and then Impeller. I loaded the app and panned around (or snapped programmatically to a lat/lon). After each step, I ran: adb shell dumpsys meminfo com.myapp.myapp TLDR: Below you will find the SKIA test with memory numbers (pay attention to GL mtrack and TOTAL), followed by Impeller test. Basically the same result, except even more GPU memory locked up. People would not see these values in devtools.
|
I haven't read through the logs in detail yet, but I suspect the first place to start would be to make sure the |
Regarding the global image cache, the only things I do are:
But to rule out anything funny, I"ll comment all those out and test again now. As far as flutter map code I do not recall ever changing anything related to image caching. Also I posted a generalized app crash issue here (since it has to do with Impeller upgrade): flutter/flutter#160941 Technically, the app STILL does crash, but not nearly as often using Skia. |
Some more testing (went back and forth twice) on Android: SKIA: The GL mtrack memory periodically goes down during map panning/zooming, and the TOTAL memory seemed to stabilize. Typically around 2 GB GL mtrack and around 3GB TOTAL. And it's more common for these values to drop by a few hundred MB from time to time. IMPELLER: Those two examples above are same app, same imagery, same general usage/map behavior. Worlds apart. UPDATE: Also toyed with NOT setting imageCache max size, vs just using the default, and, just letting system clear it when needed. Not really much difference either way. |
Well, it appears that flutter 3.27 (even when building "presumably" with impeller disabled) appears to use more memory, resulting in crashes. Either that, or something else has changed. Perhaps it is less aggressive in reclaiming memory or clearing image cache, IDK. So for now, I have reverted back to 3.24.5 :-( However, I have been working on mitigating crashes. I did two primary things:
Now, for looping, this means we are only loading 18 out of 36 frames, (1 back in case user hits back button, and 17 "ahead"). At first I was afraid that disposing the tile layer would result in new downloads, but thankfully that is NOT the case. So yay. |
I would highly recommend not loading all layers at once, and instead, changing the tile URL for a single layer and let it handle swapping out tiles. This will avoid the memory issues you are experiencing. Though, i would recommend staying on 3.24.5 for the time being, given how unstable 3.27 has been so far |
What is the bug?
When using multiple TileLayers with frequently changing urlTemplate, my application’s GPU memory usage continues to increase over time. Even after older URLs are no longer referenced, or after certain TileLayers are no longer visually needed, flutter_map appears to retain those textures in GPU memory. For example, GL mtrack over 3.5 GB before device forcibly closes the app:
How can we reproduce it?
Well, add something like 72 TileLayer(), and update each URL every 5 minutes. Pan the map around from time to time, and also run:
adb shell dumpsys meminfo com.myapp.myapp
...and watch the GPU memory grow forever.
It could be this is an issue "most" people do not bump up against, but is magnified given my situation.
Do you have a potential solution?
If it doesn't already exist, add a way to force tile disposal for old URLs and/or old keys. Possibly exposing a new “evict” API (similar to old tileStore concept).
Provide documentation clarifying how to remove stale GPU textures (e.g., remove the TileLayer from the widget tree entirely, wait for disposal, etc.)
Platforms
Galaxy S23
Severity
Fatal: Causes the application to crash
The text was updated successfully, but these errors were encountered: