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

Why are RasterMaps so heavy compared to Vector Maps? #9032

Closed
leelx78 opened this issue May 17, 2017 · 6 comments
Closed

Why are RasterMaps so heavy compared to Vector Maps? #9032

leelx78 opened this issue May 17, 2017 · 6 comments
Labels
Core The cross-platform C++ core, aka mbgl

Comments

@leelx78
Copy link

leelx78 commented May 17, 2017

Hi, I noted that vector maps are very smooth but when I add a raster map this way

RasterSource webMapSource = new RasterSource( "web-map-source", new TileSet("tileset", server+"/{z}/{x}/{y}.jpg"), 256); MAP.addSource(webMapSource); RASTER_LAYER = new RasterLayer(SATELLITE_MAP_ID, "web-map-source"); MAP.addLayerAbove(RASTER_LAYER, "water-pattern");

the raster takes a lot more time than the vector data to display. The tile format is nothing special, e.g. 6-18kB each (256x256 px) and I get the same behaviour with Mapbox "Satellite" tiles at 70% quality (jpg) so I know it is not due to the tile. Network speed is not responsible for this either as this is all cached according to my network monitors.

Can anybody let me know if this is "normal" and if there is a way to speed it up? I want to use satellite tiles for 0-5 zoom and vector tiles beyond 5 but I need the sat layer to appear very smooth.

Maybe I can load a TIFF as a map background so I know it will always be in cache? Seems very wasteful though!

Thanks

PS: using the current beta channel but I got the same behaviour with the stable, the beta and the snapshot channels

@leelx78
Copy link
Author

leelx78 commented May 17, 2017

Note: this effect is particularly visible at 60 deg tilt and pan/rotate around.

I see nearly no lag for vector tiles but it takes up to 5-8 seconds for all raster tiles to render at the horizon.

Placing the map above different layers made no difference.

@kkaefer
Copy link
Contributor

kkaefer commented May 18, 2017

What device are you using? Some devices don't have optimized JPEG/WebP/PNG decoders and will take a long time. Tilting the map exacerbates the issue since a lot more tiles are loaded. I ticketed this in #9037

@leelx78
Copy link
Author

leelx78 commented May 18, 2017

thanks @kkaefer. It's a RK3368 box with custom ROM but it looks very fast when dealing with vector tiles. I was surprised to see it was slowing down so much with jpg tiles. Usually it's the other way around.

My whole tile database is just ~30MB since I'm only using the first 5 zoom levels for satellite. Can't I just keep the tiles in memory instead of reloading it every time?

@mb12
Copy link

mb12 commented May 19, 2017

@leelx78 For tile size 256, the renderer will load 4x as many tiles than if the tile size were 512. You can specify 512 when creating the source. GL native will automatically scale your tiles to twice the size.

new RasterSource( "web-map-source", new TileSet("tileset", server+"/{z}/{x}/{y}.jpg"), 512)

Can you clarify if you are seeing low frame rate or just longer load times because the number of tiles to load is much higher?

@leelx78
Copy link
Author

leelx78 commented May 19, 2017

@mb12 I wouldn't say there are that many tiles in the viewport but I'll see if I can get 512px tiles. I got the impression 256px is a very standard size though for mapbox.

Frame rate seems fine, the tiles only take several seconds to show and you clearly see them rendered in blocks of 2-8 until they fill the horizon. The vector tiles, however are instantaneous so I thought there might be a bug somewhere, especially because we are only dealing with zoom levels up to 5..

@jfirebaugh
Copy link
Contributor

Closing; sounds like this was more of a question, and I don't think there are any actionable changes to make here that aren't captured in other issues.

@kkaefer kkaefer added the Core The cross-platform C++ core, aka mbgl label Jun 2, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Core The cross-platform C++ core, aka mbgl
Projects
None yet
Development

No branches or pull requests

4 participants