tileSize needs to be a function of device density/contentScaleRatio and not a constant 512.

[mb12]

This is a low hanging fruit to improve tile load/parsing performance by 4x on retina/higher resolution devices.

Currently for the same zoom level, on retina devices number of tiles loaded is 4x the number of tiles loaded on non-retina devices. For Vector sources, there is no need to put this limitation esp. given each vector tile has 4096x4096 resolution.

[ljbade]

Yeah I have noticed loafing tiles in high density areas like SF is a bit slow down compared to desktop and the number of tiles could be the problem.

/cc @ansis

[1ec5]

Source::getZoom() increments the zoom level when the pixelRatio is above 1. (On a Retina display, pixelRatio is 2.) TileData::request() already replaces “{ratio}” w/ “@2x” for raster sources.

[ljbade]

@1ec5 keep in mind that Android can go beyond 2x to 3x and 4x (so far).

[mb12]

This is not the right fix. The value of mbgl::util::tileSize should be a function of device density.

dpi=1, 256
dpi = 2, 512 and so on.

This way, if two devices have same physical size but different device densites, they would still render the same physical area on earth. This is the value that vector maps provide. Tilesize can be changed dynamically on the client depending on device density.

[ansis]

The units of tileSize are in 1dpi pixels. So, if the tileSize here is 256 it actually covers 512 pixels on a 2dpi screen. This means that the same tiles are loaded no matter the dpi, which is what you want for vector tiles. For raster layers you probably do want more pixels for higher dpi screens. This will be implemented by loading higher resolution tiles, not by loading more tiles of the same resolution from higher zoom level. See #919.

[mb12]

Thanks for the explanation.
I've verified that the method used to compute the number of tiles refers to width and height in points. (TransformState::cornersToBox)