-
-
Notifications
You must be signed in to change notification settings - Fork 310
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
First map rendering takes a long time when you have a lot of offline data stored #1815
Comments
2 possible alternatives to solve this issue:
|
Thanks for this super detailed bug report. Which of the two solutions you suggest would you prefer? |
With more study on this issue, i could see a third option that is better than the two previous ones. The main problem I have with the previous 2 solutions are in term of database corruption. If something wrong happens between the initial modification and the computation modification, you'll have a database with incoherent information stored. That could leads to issues difficult to overcome. A third (and my preference) solution is to split the ambient cache from the offline database cache. When we need to store resource for ambient cache:
When we need to store tile for ambient cache:
When we need to store resource for offline data:
When we need to store tile for offline data:
(*) Even if something wrong happens and the delete instruction cannot be done for a specified resource/tile, that only means the ambient cache will waste some size. By doing this, the initialization of the ambient cache will take no time, because we'll doing the request on a table that is limited to the Max Ambient Cache Size anyway. About database structure migration, we can simply clear the ambient cache at first upgrade to the new database version. Maybe a design proposal for this kind of modification could be useful? |
Hello. What do you think about the implementation of the third option (via the two new tables We could start working on that change this week in order to implement it this month. Thanks in advance. |
It sounds like a solid plan! 👍 If you can basically copy what you wrote in a design proposal template and make a PR, that would be helpful. Thank you for looking into this and I'm looking forward to having this issue resolved. |
Thank you, we have created the design proposal template and made a PR : #1839 |
Describe the bug
I found a nasty issue on MapLibre native when you have a lot of data downloaded. The time for the map first rendering increases significantly. With 1,5GB of offline data, the first map rendering lasts 5 seconds instead of 1 second.
To Reproduce
Steps to reproduce the behavior with the test app:
The time increases as the local database also increases.
The referenced style includes multiple sources that emphasizes the issue, but you can use any style that includes sources with a lot of data.
Expected behavior
A first map rendering that takes the same time or near the same time as when no offline data are stored.
Screenshots
https://github.com/maplibre/maplibre-native/assets/13694294/a7c2bf01-54ff-43ed-86b1-675efb79e00a
Platform information:
Additional context
Historically, this issue was found in Mapbox in 2020 : mapbox/mapbox-gl-native#16519
I searched in the code and I agree with the initial issue : the initialization of the ambient cache size (
OfflineDatabase::initAmbientCacheSize
) takes a long time when the database gets a lot of stored tiles.I modified the code by ignoring the request and returning directly 0 for the ambient cache size, and the first map rendering was instantly done.
The text was updated successfully, but these errors were encountered: