TileLooper calculates wrong number of required tiles when map repetition is disabled

[Maradox]

Issue Type

[x] Bug

Description and/or steps/code to reproduce the problem

TileLooper.loop calculates mTiles, which represents which tiles are currently visible on the screen.
TilesOverlay.OverlayTileLooper.initialiseLoop uses this mTiles to calculate the total numbers of tiles and calls mTileProvider.ensureCapacity to ensure the MapTileCache is big enough to hold all the tiles.

This works fine for maps which have set isHorizontalMapRepetitionEnabled and isVerticalMapRepetitionEnabled to true (horizontalWrapEnabled and verticalWrapEnabled set to true in TileLooper).

However, when isHorizontalMapRepetitionEnabled and/or isVerticalMapRepetitionEnabled is set to false mTiles may be incorrect and thus resulting in a wrong cache-size in MapTileCache.

Example:
Set isHorizontalMapRepetitionEnabled and isVerticalMapRepetitionEnabled to false.
When zoomed out on zoom level 1 we get the following mTiles = Rect(-1, -2 - 2, 3) while we should get Rect(0, 0 - 1, 1).
Thus MapTileCache increases its cache-size to 24 instead of 4.

Environment

If it's a bug, version(s) of android this affects:

All

Version of osmdroid the issue relates to:

6.1.17

[emandtf]

I just tested and it doesnt' seems a bug.
You're right when saying "if MapRepetition(s) are enabled then MapTileCache has a wrong value" but the "wrong value" is "just" its Capacity.
No any Tile is loaded for not-visible Tiles (those that could be repeated) as you can show in "TileLooper.java" in "loop(...)" method: Tiles are handled/generated only if "horizontal/vertical wrap is Enabled OR the tile is within indices view boundaries".

My example at zoom 1:

• mTiles: Rect(-1, -2 - 1, 1) which means a viewport of width=2 and a height=3 for a total of (2+1)*(3+1)=12 tiles (with 1 extra tile summed)
• Overshoot (setting "osmdroid.cacheTileOvershoot") was set (default?) to "12" for me
• mTileCache.mCapacity = 12 (tiles included extra tiles) + 12 (for overshoot) = 24 total cache Capacity
• in "TileLooper.loop(...)" method the final "handleTile(...)" method is called only for ONE tile (the only one displayed which owns whole world), so for 23 cycles the nested FORs are skipped without do nothing

TileCache Capacity is NOT current cache Size but only "how much items it CAN handle before require a re-hashing of items".
On my display 12 (3*4) seems to be the minumum Cache size and Capacity, so it's not a big deal if 11 Tiles are cached at Zoom 1 (which is rarely or just temporarily used) because usually those will be overwritten quickly at higher zoom levels.

[Maradox]

You are absolutely correct with your assessment. The bug doesn't cause loading more tiles than needed.
But setting a higher capacity than needed leads to keeping more tiles in memory than would otherwise be required.
In the long run the issue might not be as problematic, because when the user zooms in he may eventually cause a viewport which leads to the same capacity as the current bug.

[emandtf]

Tiles are just retained in the minimum Cache size, so if at Zoom 1 only one is required the other cached tiles are just "there as they were". In fact in my test 11 tiles were of simple Water (because I come from an higher zoom) and only one is about the whole world.
Maybe would you like to let Cache to be down-sized to 1 in that specific situation?
I'm not sure how much ppl are using maps by having only one single Tile provided with whole word and the rest of them filled with black color.....