Tile Size about tileview HOT 6 CLOSED

Hey again Phil,

Tile size really only matters for edges. Say a viewport has one edge where each tile is only overlapping by 1 pixel - it still has to decode the whole tile for each of them to render. In general, a smaller tile size is always going conserve the most amount of bitmap memory, but can be less efficient in terms of total file size, and the number of decodes. If you're getting missing edges, I'd drop your tile size by 50%, but probably no more than 128 (maybe 64 if you have a limited number of tile sets), but that's probably the only time I'd worry about it.

The most important thing to worry about as regards memory usage is having enough tile sets - and this is something I think is probably not obvious. Each tile is going to use the same amount of memory regardless of how scaled it is, so when you end up with a bunch of scaled-down tiles because there's not a smaller tile set, this really kills bitmap budget. You really want at least one tile set half the size of the first, until that size becomes smaller than is likely to be viewed (e.g, smaller than a typical device). LMK if that doesn't make sense.

"Visible performance" - how smoothly everything runs - is actually affected (surprisingly, to me anyways) the most by paths. You'll notice even a small simple path in one area of the TileView can cause dragging to be jumpy, and a more sophisticated one (e.g., with a shadow effect, or just with lots of points) can slow it to a crawl. Also, tile transitions are pretty heavy - if you're not getting great performance (but it's not a bitmap budget issue), try disabling transitions.

Finally, caching - which is (as always) a complicated topic. IMO, I only enable caching if I'm using a relatively small map with relatively few tile sets. Both on-disk and in-memory cache are "least recently used" and have a hard cap (8MB, and 25% of available), so really it's only a benefit if the user is going to be seeing (and decoding) the same tiles with relative regularity/predictability.

HTH

from tileview.

Thanks for your detailed reply - that all makes sense.

I've now reduced my tile size by around 50% to 250x250 although this does not appear to have solved the problem. I believe it's a form of memory issue with my implementation as when you first load the TileView the performance is very slow and it struggles to scroll/zoom whilst the heap size increases. Once the heap size get's to around 50MB the performance is perfect and there seem to be no more issues. Is there any way to get around this? I've tried with your sample application (MapView) and this does not seem to fall foul of this problem. The main differences as far as I can see is that your tiles are complied in as assets whereas mine are decoded from the SD card.

Thanks again for your help.

from tileview.

Hmm... I'm not sure I can offer any advice on how to more efficiently decode from the SD card (stackoverflow might be a good place to find that kind of info)... Assuming you're using enough tile sets (i'll emphasize again that IME this is the most important single consideration), don't use paths, have transitions disabled, and caching is either on or off as appropriate, there's not much else I can think of.

Have you tried decoding your images from assets - not permanently, but just to confirm the source of the issue?

from tileview.

@phil-applegate did this get resolved? if not, is there anything else I can do to help? otherwise, please let me know if i can close the issue. thanks

from tileview.

Hi,

I've looked into more efficient decoding from the SD card and it looks like there is not much more that can be done from that sense. I've tried having no paths, no transitions and disabling caching all to no avail.

That said I've not got around to trying to decode from assets yet, If I get some time I'll investigate further and try to narrow the problem down. For the mean time will close the issue and re-open should any more information come to light.

Thanks for your help.

from tileview.

Sounds good

from tileview.