Persistent caching of vector map tiles?
Displaying vector map tiles is quite slow, because they are computed on demand using the mapsforge library.
If I zoom in and out repeatedly in the same region, the map is displayed much faster, so there seems to be some kind of caching for the computed tiles.
However, this cache does not seem to be persistent, as after a restart of Locus displaying the same region is quite slow again.
Would it be possible to (optionally) store/cache every computed tile from a vector map in a local sqlitedb, as it`s already done with online maps? With the option to define a maximum size for this cache and another option to switch it off totally (for those lucky guys with a high speed CPU in their mobile...)?
Changing the map theme and refreshing the vector map should invalidate the cache, of course.
I like this idea 
Hi Mambo,
you correctly noticed that Locus partially cache vector maps tiles. It`s not correct that it remove all data during start. I leave 500 last used tiles, rest is removed during start. So last used location should start fast.
anyway this wish depend on few facts. You have slower phone, for example on Galaxy nexus, there is no huge difference between cached and generated tiles. Also if MapsForge create faster rendering, this will be useless. I think that such system do not worth it. Also will be a problems with new map files, with clearing content of SQLite cache based on vector theme etc, really a lot of work ... so Idea denied, sorry
Hi Mambo,
you correctly noticed that Locus partially cache vector maps tiles. It`s not correct that it remove all data during start. I leave 500 last used tiles, rest is removed during start. So last used location should start fast.
anyway this wish depend on few facts. You have slower phone, for example on Galaxy nexus, there is no huge difference between cached and generated tiles. Also if MapsForge create faster rendering, this will be useless. I think that such system do not worth it. Also will be a problems with new map files, with clearing content of SQLite cache based on vector theme etc, really a lot of work ... so Idea denied, sorry
Hey Menio
i observe, that Locus just caches the MapsForge-computed Tiles in /mnt/sdcard/Locus/cache/map/vector/
There _are_ several files with a hex-coded-filesname. These files are obviously PNG-formatted bitmaps with a size of 256x256 Pixel.
I would say: this is a caching, even when it`s not a SQLite-DB.
So my question is teh other way round: why do you write dem to SD-Card? This makes the Vector-Map-Display unnecessary slow, needs CPU for PNG-encoding, needs Battery (for writing to the SD-Card) and my SD-Card is getting older and older with every flash.
Just disable this or offer a Checkbox-Switch somewhere to manually disable this.
Greetings from switzerland
Oli
Hey Menio
i observe, that Locus just caches the MapsForge-computed Tiles in /mnt/sdcard/Locus/cache/map/vector/
There _are_ several files with a hex-coded-filesname. These files are obviously PNG-formatted bitmaps with a size of 256x256 Pixel.
I would say: this is a caching, even when it`s not a SQLite-DB.
So my question is teh other way round: why do you write dem to SD-Card? This makes the Vector-Map-Display unnecessary slow, needs CPU for PNG-encoding, needs Battery (for writing to the SD-Card) and my SD-Card is getting older and older with every flash.
Just disable this or offer a Checkbox-Switch somewhere to manually disable this.
Greetings from switzerland
Oli
Hello, good observation.
caching of vector maps is because of simple reason. Cached maps are loaded more then twice as fast then rendering of new tiles on an average phones. On new phones, this difference isn`t so big but still, it`s there. You may check it when you move map to some new location and then return with for example centering button back. Loading from cache takes less CPU then rendering new tiles.
Only think you`re correct is that it require access to SD card. Do you really think that often access to SD card reduce service life a lot? I think that most people buy bigger once much sooner before card should be destroyed by some life limits
Hello, good observation.
caching of vector maps is because of simple reason. Cached maps are loaded more then twice as fast then rendering of new tiles on an average phones. On new phones, this difference isn`t so big but still, it`s there. You may check it when you move map to some new location and then return with for example centering button back. Loading from cache takes less CPU then rendering new tiles.
Only think you`re correct is that it require access to SD card. Do you really think that often access to SD card reduce service life a lot? I think that most people buy bigger once much sooner before card should be destroyed by some life limits
I currently have this problem that i get more and more Kernel-Faults while accessing SD-Card. (i see it in /proc/last_kmsg).
And - really - my SD-Card get`s warm while i use Locus with Vector-Maps.
You say, that it`s faster when reusing cached tiles. But that`s only true if i scroll back to a already-computed-and-cached area, right? So it`s not faster in _every_ situation. And it depends on the speed of the SD-Card compared to the CPU-Performance.
And every SD-Cards get`s slower and slower because of the non-existing TRIM-Feature (http://de.wikipedia.org/wiki/TRIM) in Android together with the VFAT formatted SD-Card.
I tried a now a little bit - scrolling around in my switzerland.osm-Map. Now i have 665 files in the ../cache/map/vector-Folder. They use 24 MBytes.
On the next Start of Locus, the folder is trimmed to exactly 500 tiles, now using 18 MBytes.
But: i don`t have the feeling that it starts faster, compared to the case, when i delete all files with a "rm *" just _before_ i start Locus.
I suggest that you offer a checkbox-switch where one can choose whether to use this SD-Card-caching-feature or not, and if, how many tiles (or MBytes) one want to use (perhaps i want to use 100`000 cached tiles with 1000 MBytes - why not, if my SD-Card is big enough).
An alternative idea could be: Caching in Memory (using a java.util.LinkedHashMap :-). I know we have just 24 or 32 MB of Heap - but 500 Tiles need about 18 MBytes - so it`s not far, far away from being possible.
Or you can `outsource` the Memory-Caching to a second Process (or a service, so it survives Restarts of the Locus-App).
One more idea: don`t cache the rendered tiles. Better cache the original vector-data ;-) That could speedup the rendering as well.
Oli
I currently have this problem that i get more and more Kernel-Faults while accessing SD-Card. (i see it in /proc/last_kmsg).
And - really - my SD-Card get`s warm while i use Locus with Vector-Maps.
You say, that it`s faster when reusing cached tiles. But that`s only true if i scroll back to a already-computed-and-cached area, right? So it`s not faster in _every_ situation. And it depends on the speed of the SD-Card compared to the CPU-Performance.
And every SD-Cards get`s slower and slower because of the non-existing TRIM-Feature (http://de.wikipedia.org/wiki/TRIM) in Android together with the VFAT formatted SD-Card.
I tried a now a little bit - scrolling around in my switzerland.osm-Map. Now i have 665 files in the ../cache/map/vector-Folder. They use 24 MBytes.
On the next Start of Locus, the folder is trimmed to exactly 500 tiles, now using 18 MBytes.
But: i don`t have the feeling that it starts faster, compared to the case, when i delete all files with a "rm *" just _before_ i start Locus.
I suggest that you offer a checkbox-switch where one can choose whether to use this SD-Card-caching-feature or not, and if, how many tiles (or MBytes) one want to use (perhaps i want to use 100`000 cached tiles with 1000 MBytes - why not, if my SD-Card is big enough).
An alternative idea could be: Caching in Memory (using a java.util.LinkedHashMap :-). I know we have just 24 or 32 MB of Heap - but 500 Tiles need about 18 MBytes - so it`s not far, far away from being possible.
Or you can `outsource` the Memory-Caching to a second Process (or a service, so it survives Restarts of the Locus-App).
One more idea: don`t cache the rendered tiles. Better cache the original vector-data ;-) That could speedup the rendering as well.
Oli
Hello Oliver,
I discovered that I leaved this discussion without answer.
Don`t know if you noticed change. I was thinking, that small phones with smaller displays are also less powerful and display much less tiles. So for them, caching on card is enabled. For bigger and much more powerful phones is rendering disabled. They can render maps really fast and need them quite a lot.
I read some more info about live of sd card and have to confirm what you say. So this solution will help a lot right? So for small and medium (till around 640x480px), caching is enabled, for bigger is disabled
Hello Oliver,
I discovered that I leaved this discussion without answer.
Don`t know if you noticed change. I was thinking, that small phones with smaller displays are also less powerful and display much less tiles. So for them, caching on card is enabled. For bigger and much more powerful phones is rendering disabled. They can render maps really fast and need them quite a lot.
I read some more info about live of sd card and have to confirm what you say. So this solution will help a lot right? So for small and medium (till around 640x480px), caching is enabled, for bigger is disabled
Hi Menion
i`m up-to-date with my "Locus pro" (Version 2.5.2) on my HTC Desire. This has 800x480 Pixel Display, which is more Pixels than you mentioned.
But: Locus still creates cache-Files in /mnt/sdcard/Locus/cache/map/vector.
Bump. I discovered nothing. There is no change. Sorry.
I think: You can not decide, when it`s wise to use caching and when not. You propose to use the screen-resolution. But that makes no sense in my opinion. You should better compare the SD-Read-Speed, SD-Write-Speed and CPU-Performance.
And what if the User "let`s the mp3-music play" in the background while using Locus? Then the Music-Player also occupies SD-Transfer-Bandwidth.
So again: why don`t you offer a simple Settings-Checkbox for this. There are hundreds of Setting-Options and most of them are useless for most people. So there is no matter if there is one more.
Greetings
Oli
Hi Menion
i`m up-to-date with my "Locus pro" (Version 2.5.2) on my HTC Desire. This has 800x480 Pixel Display, which is more Pixels than you mentioned.
But: Locus still creates cache-Files in /mnt/sdcard/Locus/cache/map/vector.
Bump. I discovered nothing. There is no change. Sorry.
I think: You can not decide, when it`s wise to use caching and when not. You propose to use the screen-resolution. But that makes no sense in my opinion. You should better compare the SD-Read-Speed, SD-Write-Speed and CPU-Performance.
And what if the User "let`s the mp3-music play" in the background while using Locus? Then the Music-Player also occupies SD-Transfer-Bandwidth.
So again: why don`t you offer a simple Settings-Checkbox for this. There are hundreds of Setting-Options and most of them are useless for most people. So there is no matter if there is one more.
Greetings
Oli
hmm good I took this topic back. There was indeed stupid issue when in most cases, cache was not disabled. So it will be disable since next version.
"There are hundreds of Setting-Options and most of them are useless for most people" - that`s true. It`s because I was adding all useful settings into Locus since begin. If you noticed, there is very low, almost zero of new settings. I`m trying to reduce these number instead of increasing.
For same reason I don`t want to add such settings, because I think, most people will not see difference between enabled/disable on first sight and settings will be only confusing for them, like: "why cache vector maps, when they are already downloaded, this is nonsense"
I`ll think about it later but for now this behaviour is fixed and since next version, caching will be disable on your device
hmm good I took this topic back. There was indeed stupid issue when in most cases, cache was not disabled. So it will be disable since next version.
"There are hundreds of Setting-Options and most of them are useless for most people" - that`s true. It`s because I was adding all useful settings into Locus since begin. If you noticed, there is very low, almost zero of new settings. I`m trying to reduce these number instead of increasing.
For same reason I don`t want to add such settings, because I think, most people will not see difference between enabled/disable on first sight and settings will be only confusing for them, like: "why cache vector maps, when they are already downloaded, this is nonsense"
I`ll think about it later but for now this behaviour is fixed and since next version, caching will be disable on your device
Replies have been locked on this page!