Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

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

Closed
mb12 opened this issue Feb 19, 2015 · 6 comments
Labels
Android Mapbox Maps SDK for Android iOS Mapbox Maps SDK for iOS performance Speed, stability, CPU usage, memory usage, or power usage

Comments

@mb12
Copy link

mb12 commented Feb 19, 2015

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
Copy link
Contributor

ljbade commented Feb 19, 2015

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

@ljbade ljbade added iOS Mapbox Maps SDK for iOS performance Speed, stability, CPU usage, memory usage, or power usage Android Mapbox Maps SDK for Android labels Feb 19, 2015
@1ec5
Copy link
Contributor

1ec5 commented Feb 24, 2015

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
Copy link
Contributor

ljbade commented Feb 24, 2015

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

@1ec5 1ec5 closed this as completed in 1c4369f Feb 25, 2015
@mb12
Copy link
Author

mb12 commented Feb 25, 2015

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
Copy link
Contributor

ansis commented Feb 25, 2015

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
Copy link
Author

mb12 commented Feb 25, 2015

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)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Android Mapbox Maps SDK for Android iOS Mapbox Maps SDK for iOS performance Speed, stability, CPU usage, memory usage, or power usage
Projects
None yet
Development

No branches or pull requests

4 participants