Fixes a tile scaling bug that resulted in low level tiles creating a peculiar mosaic on intensive zooming to non-predownloaded areas.

Review Request #123306 - Created April 9, 2015 and submitted

Adam Dabrowski

Update: Now fixes the issue by bounding the scaled aread to a minimum of 1 pixel

Doesn't change functionality.

Does clarify the code as flow was very non-intuitive previously (especially in case when deltaLevel > 8 for tileSize = 256).

if/when the scaledLowerLevelTile "for" loop reached zoom level where 2^deltaLevel > tileSize, a peculiar thing was happening.
In this situation, in part "// which rect to scale?", the image was copied first from 0 sized-image. Calling the QImage::copy function with null rectangle (or 0 width and 0 height) results in copying a whole image instead. As a result, instead of level_N tile, a level_N-9 (or later) tile was returned unscaled, resulting in curious displays (i.e. multiple copies of the same tile image).
While for textures that are downloadable this was a temporary case, offline textures would just stop there and display this curious images. Additionally it was very unclear and took me some time to figure out what's happening.

This version does clearly what previously was done due to specific QImage::copy behaviour.

Let's discuss if this behaviour is desired (or we want to display a full white opaque tile or a tile with a loading icon if there are download urls etc.).

Tested with unbounded second layer (partial) of texture, where the bug formerly was very easy to detect. Also tested with fast zooming to non-predownloaded areas. Works well.

Tested with zooming in and out and two layers of texture as well as one. No change noticed (as intended).

Torsten Rahn
Adam Dabrowski
Adam Dabrowski
Torsten Rahn
Adam Dabrowski
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted with commit f0542388a3271d6504e6e0b7b403f9d09ac1d7e2 by Dennis Nienhüser on behalf of Adam Dabrowski to branch Applications/15.04.