thirst thanks for the great work!
I updated my app from route-me to MapBox in the last weeks and had a problem with online tile sources. The same behavior was discussed for offline tile sources in the issue #110.
I traced down the process getting the tiles and found a "solution".
All good at this moment, but when the drawLayer is the next time called, all started from the beginning, because the added image isn´t added. It´s skipped because of the kWriteQueueLimit. If the limit is set to 15 quered operations and the user zooms to a high zoom level where so much tiles downloaded that it skips adding, sometimes a loop starts between "downloading the real zoom and adding to cache" and the "using of the lower res image".
In the code there is the comment: "Don't add new images to the database while there are still more than kWriteQueueLimit insert operations pending. This prevents some memory issues.". So I ask I there is a better way as increasing the limit...?
Are you still seeing this as of the latest develop? Not sure I understand the problem entirely.
Looks like I have the same problem in develop branch. Map is twitching. Currently video is processing by vimeo (and will be available here http://vimeo.com/53963575). I use routeme.plist file with "type":"memory-cache", "capacity":4 to avoid caching, maybe here is a problem.
Ah, yes, disabling disk cache could have this effect. I will see if I can adjust that.
Cool, big thanks!
Give the above a try? It's a branch. I need to fix up some API if this works.
Yep, now much better! just assign initially databaseCache to nil, in another case crash.
fixes #138: add more cache API & detect cache before trying async loads
sorry for the very late response. I was very busy in the last weeks.
I tested the develop branch including your fix and have the save issue. If the QuereWriteLimit exceeds it was possible that the tiles jitter again. The problem then was that the not cached tiles loaded again and again and could not be cached.
I´ve done something that prevents that. First I purge the database only if there are more than 100 tiles over the limit. Without that the purge will be called for each new tile above the limit.
The second thing is I added a "2nd level" memory cache. If the write quere is full, the tile will be cached in the memory. If the tile is requested again, it search in the memory cache before searching in the database cache.
Here are my changes:
Does this happen to work with just the 100 tile tweak? Or is the cache level ordering important to it as well?
Not completely. The issue appears not so fast with the 100 tile tweak, but the possibility for it exist.
It only appears on devices (not in the simulator because the Mac is to fast in storing the tiles to the database) with a fast internet connection (on EDGE or something similar the storage of the tiles is faster than the download). If the user scrolls and zooms the map very fast the save operations in the queue raises. If the save of a tile is skipped and it should drawn a second time, the mapsource looks in the cache, did not found the tile, displays the zoomed in tile of the upper zoom level, loads the tile, displays it and trying to store it.
So the jitter effect comes. If the second try to store the tile is skipped to, it jitters again. With only 15 write operations (and a full cache database with a purge after every tile) there is a good chance to get a loop (and it jitters for minutes..).
I think with the increase to 100 and the "purge only if +100 tiles" the chance to get the issue is small.
But the increased limit haves another problem: If the tile is requested again, the map source asks the cache for the tile. If the tile is already in the queue, the cache don´t finds the tile (because it only looks in the database) and the map source downloads the tile again (and gibe it to the cache again).
This morning (when I read your question) I had another idea I want to test the next days:
With this logic there is no lag between the download and the availability of the tile in the cache..