Color relief performance

[averas]

I have started "porting" one of my old raster based shaded relief implementations to GL but immediately ran into some indications that performance might be an issue, and hoped that there might be some good insights as to why.

Basically my setup consists of contour lines, color relief and hillshade. So far I've managed to get the contours and color relief working in GL using vector tiles. The contours work fine and as expected; it's when I added the color relief signs of problems showed up.

The color relief is polygonized from rasters and then I dynamically set up layers with filters achieving the following:

It does work quite well overall, but zooming and panning becomes choppy and CPU runs high as zoom levels increase. I experimented some between having overlapping polygons and masked polygons, and even though I got the impression that the latter was a bit more performant it still runs heavy on my high end Mac.

Any clues as to why this is challenging? It seems to me that Mapbox streets contains similarly complex areas.

Is adding layers very expensive (I have streets+20 in my test)?
Is the fact that I have filters (elevation) on these layers expensive?
Could it be that my polygons are too detailed (I haven't simplified them at all)?
Is there some collision control between these polygons going on?

[averas]

I've fiddled around some more and it definitely seems like it's the number of layers, not the data itself, that causes performance issues.

[kristfal]

Hey,

don't have answers to all your questions, but I've been experimenting quite a lot with performance optimizations (in particular on mobile devices).

In general, it seems like the no. 1 rule is to keep the amount of layers in the style.json to a minimum – even if it would mean duplicating vector data in the source, for instance by grouping data layers that has similar fill rendering color into a separate layer.

Beyond that, I'd recommend using the tessellation branch, it does wonders on fill-intensive styles. And a heads up, if you're using custom data, make sure your polygons have the correct winding order with the tessellation branch.

If you could post an example of the style you're making, I could have a look to see if you could shorten it somehow.

On a 💭 , I'd be really happy if some of the mapbox folks could share best practice for creating high-performance styles. For instance, what is the performance hit of antialiasing fills? Does filters have a significant cost? What about opacity for fills, symbols or lines? Line caps? Sprite sheet sizes?

[averas]

Thanks for your feedback!

Keeping the number of layers as low as possible sounds reasonable, however, until something like #1626 is done I think the only way to achieve a color relief is to have multiple layers with filters for each color step.

I tried out the earcut-final branch, and just as you said, it was substantially more performant for the color relief polygons, actually to a degree where I couldn't tell it was slower than other areas.

[mourner]

Yes, the number of layers affects rendering performance severely. We're actively pushing towards data-driven styling #1626 to solve this. Another reason might be that polygon fills are currently expensive, and you might get better performance with earcut-final branch. #1606

[averas]

@mourner Yes, on @kristfal 's suggestion I tried out the earcut-final branch and it was a lot more performant. Looking forward to see it merged!

[averas]

@mourner You wrote that the number of layers affects rendering performance severely.

Just to dig a bit into this - could you briefly elaborate on how rendering cost differs between:

• A layer with a vector tile source without any data (i.e. still fetching tiles)
• A layer with a GeoJSON source without any features
• A layer with source data but with its visibility set to none
• A layer without source data and its visibility set to none (is this close to equally cheap as no layer at all?)

[mourner]

@averas performance should be affected by every layer that is rendered (e.g. visible, with data, etc.), because each layer requires a separate set of WebGL draw calls which are expensive.

[averas]

Cool, thanks.