Skip to content

Loading…

Jitter tiles between different zoom levels #138

Closed
Looking4Cache opened this Issue · 10 comments

3 participants

@Looking4Cache

Hi,

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".

What happens:

  • RMMapTiledLayerView drawLayer: tries to get the image, asks by TileSource -> TileSource looks up in cache -> not found -> requests from web
  • drawLayer tries to get a lower zoom to use this instead
  • the image from the web arrives, trying adding to the cache and displayed

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...?

Best, Thorsten

@incanus
Mapbox member

Are you still seeing this as of the latest develop? Not sure I understand the problem entirely.

@incanus incanus closed this
@kirillkudin

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.

@incanus
Mapbox member

Ah, yes, disabling disk cache could have this effect. I will see if I can adjust that.

@incanus incanus reopened this
@kirillkudin

Cool, big thanks!

@incanus
Mapbox member

Give the above a try? It's a branch. I need to fix up some API if this works.

@kirillkudin

Yep, now much better! just assign initially databaseCache to nil, in another case crash.

@incanus incanus closed this in 1c24976
@Looking4Cache

Hi,

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:
Looking4Cache@998b691

Best,
Thorsten

@incanus incanus reopened this
@incanus
Mapbox member

Does this happen to work with just the 100 tile tweak? Or is the cache level ordering important to it as well?

@Looking4Cache

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:

  • Tile should be added to cache -> The cache first puts the tile-image and a key to a dictionary. -> The cache stores the tile-images from the dictionary to the database, after the save is completed the tile will be removed from the dictionary.
  • Tile should be readed from the cache -> The cache looks in the dictionary first and after this in the database.

With this logic there is no lag between the download and the availability of the tile in the cache..

Best, Thorsten

@incanus
Mapbox member

Outdated.

@incanus incanus closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.