-
Notifications
You must be signed in to change notification settings - Fork 61
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
investigate excessive memory usage while zooming #24
Comments
here's what I've found so far: Vector tiles, when decoded from protobuf, consume a lot of memory, easily exceeding 1GB.
During zooming the problem is exacerbated, because there are more tiles on the map, and if you zoom quickly enough you can have processing on isolates that is no longer needed due to tiles having been requested but not completed processing. The queue of work can easily get over 50. My plan to address it:
|
Reduce memory overhead by eliminating decoded vector tile cache. Introduced a byte cache of vector tile data. issue: #24
execute tasks in LIFO order to improve responsiveness when a queue starts to grow. This also incrases the probability that some tasks become obsolete before they are even started. issue: #24
Introduce executor jobs to facilitate additional job parameters. issue: #24
Introduce executor support for job cancellation as an optional job parameter. issue: #24
eliminate unnecessary processing by cancelling tasks that are no longer needed. This is useful when a user interacts with the map quickly, since tiles can be disposed before processing completes. issue: #24
make debugging more comparable to release mode by using an isolate to process jobs. This helps to expose issues such as job queueing. issue: #24
Disable isolates since they exacerbate the memory growth problem. Add QueueExecutor which adds deduplication to scheduled jobs. issue: #24
eliminate use of streams, which need to be closed. instead, provide a list of futures. Streams may have been the source of the memory issue that caused RSS growth. issue #24
Experiment on flutter-vector-map-tiles/tree/memory-investigation learning so far:
|
I've managed to find a way to reliably reproduce the issue, and have found that the raster cache grows suddenly when panning over the Vancouver subway at a high zoom (14-16) Memory jumps when rendering one (or both) of the following:
More investigation is needed to determine the root cause. |
Further experimentation has lead me to observe that Raster Picture memory usage remains nominal as long as the map zoom is not far beyond the tile zoom. In my example, map tile data is limited to a maximum zoom of 14, whereas I have the maximum zoom of the map set to 20. The map layer will allow zooming beyond the maximum zoom of the tile data by rendering tile size 14 at the map zoom size (in this case, up to 20). When I have the map zoomed to level 14, I don't see any Raster Picture memory usage on the memory timeline. Following is a zoom level to observed RasterPicture memory usage:
Memory usage varies depending on the tile being rendered, with some tiles needing much less than observed. My current theory is that Canvas must allocate memory to render details outside of the visual area, and that the amount of memory used corresponds both to the size of the canvas and to the level of detail in the tile. Increasing the difference between the tile zoom and the map zoom causes increased memory usage, so should be limited to devices that can supply the necessary memory. A viable workaround is to limit the maximum zoom of the map to the same as the maximum available tile size, or within one level higher. Recommendation: For maps that display on mobile devices, with a map tile with maximum zoom of 14, limit the map maximum zoom to 15. |
Can the canvas be restricted somehow to not allocate memory outside the drawing area? I also saw the the renderMode setting was removed, especially "raster". A bit above raster cache is mentioned. Is this still an issue? (currently I am experimenting with |
Not that I'm aware of. Feel free to open a ticket with the flutter team, perhaps this is something that they could fix. The raster cache has been removed completely so it should no longer be an issue. |
Thanks, unfortunately I don't have the background knowledge to open a ticket with the flutter team. Thanks for the impressive work on this module. |
You’re welcome!
Out of curiosity why do you want such a large zoom offset?
…On Sun, Jun 19, 2022 at 10:32 AM Alexander Menk ***@***.***> wrote:
Thanks, unfortunately I don't have the background knowledge to open a
ticket with the flutter team.
Thanks for the impressive work on this module.
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEKDQ7VFSXLDU43BR7ZYH2DVP5KUNANCNFSM5MBF4JHQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***
com>
|
@greensopinion I believe the standard openmaptiles only support zoom level 14 and in our app we want to be able select positions with a higher accuracy (zoom 18) I am wondering if this canvas problem also effects performance in other regards. |
I'm using zoom 14 tiles at zoom 16 without issue. To go higher, I recommend looking at another source of tiles. For example, Mapbox goes to zoom level 22. Performance of native and web-based map libraries is much better. This library has a long ways to go to get rid of jank fully. Performance is much better without memory pressure, so avoiding over-zooming will help. |
Memory usage can spike occasionally while zooming. Sometimes it's severe enough for iOS to terminate the app.
I can reproduce this on the example app by zooming in/out in an area such as Los Angeles or San Francisco where there is a lot of detail on the map.
The text was updated successfully, but these errors were encountered: