improve layer opacity performance

[ansis]

• check if the memory for the render textures is reallocated on each frame (we were!)
• render the composited layer into the texture right before using it, not at the start of the layer group. This should reduce the number of render textures needed by a lot

Also, we should think more about how we can prevent double drawing without rendering into a texture. With the depth buffer we can prevent double drawing, but this falls apart near edges where we have antialiasing. We could draw antialiasing for lines in a separate draw calls to solve this problem for a single layer, but overlapping lines with different colors would still be aliased where they meet. We should also check whether availability and performance of msaa is good enough that we could drop our own antialiasing.

[ansis]

• check that we're not drawing it tile by tile

[ansis]

The way we draw composited layers right now causes a lot of stencil redraws. Reducing this may help a lot.

Also, instead of copying the entire canvas it may be cheaper to use the line geometries to only copy those pixels. More vertex shading but less fragments.

[ansis]

So, we were re-allocating the texture on each frame which was really, really wasteful. Fixed in
0e9c6c1

@nickidlugash @edenh using composited layers should be ok now, but keep an eye out for what the performance impact is. I'm not sure what it is now, but it should be much lower than before. And it shouldn't crash your computer

[mourner]

@nickidlugash any update?

[ansis]

@kkaefer @nickidlugash @mourner

I think we should remove support for composited layers. They are too slow to be usable. For example, removing the single composited layer from the osm-bright style improves framerate by ~33% (from 30fps to 40fps). I don't think we can improve performance enough for composited layers to be practical.

---

Why is it slow?

• Binding the framebuffer is slow. Not sure why. Maybe copying the previous buffer contents to some other memory is bottlenecking framebuffer memory bandwidth.
• setting up the stencil mask is slow
• clearing the color and stencil buffers is slowish
• rendering into a texture seems slower, no idea why
• copying a full screen of fragments is slow

Some of these could be optimized (don't use a stencil or depth buffer, copy fragments with the geometries instead of a full screen quad), but probably not enough. @kkaefer does this sound right?

---

There are a couple ways we could try to achieve the same or a similar end result. I think they would all be too much work to be worth it any time soon.

• union/clip geometries to prevent double drawing
• use a sdf
• use a prerendered low-res texture with the background color values for blending

[yhahn]

I think we should remove support for composited layers. They are too slow to be usable.

@ansis walked me through all the options he was thinking about here. Composited layer effects are obviously a necessity, not a nice-to-have, but it sounds like the approach we have now is a trap, not a feature. It's probably better to remove traps early rather than letting people get attached to them and get burned later.

Conclusion was that we should disable this now and fight this fight another day.

[mourner]

I think we should remove support for composited layers. They are too slow to be usable.

I had this impression too, and performance is our top priority. It's too easy to make a style totally unusable by using compositing.

@nickidlugash can you show us the kind of artifacts we get by totally eliminating compositing and using opaque colors for road casings (preblended over most common background color) in some of our styles? It seems that they shouldn't be worth the 33% performance drop.

[kkaefer]

I agree that it might be good to drop it now and consider re-adding it later, once we looked at other ways of achieving similar visual effects.

What I've also found is that binding/unbinding framebuffers is typically the slowest part. The best approach for rendering a frame is to first bind the framebuffer, render everything into the framebuffer, then unbind it, continue with rendering the remainder of the frame and use the framebuffer texture when we need it. I.e. we shouldn't render part of the frame to the main buffer first, then bind the framebuffer, render and unbind, and then composite.

[ansis]

The best approach for rendering a frame is to first bind the framebuffer, render everything into the framebuffer, then unbind it, continue with rendering the remainder of the frame and use the framebuffer texture when we need it.

Yeah, we're already doing this

[nickidlugash]

can you show us the kind of artifacts we get by totally eliminating compositing and using opaque colors for road casings (preblended over most common background color) in some of our styles? It seems that they shouldn't be worth the 33% performance drop.

See adventure style – I've already removed composites from these road styles by using line-offset to style casings rather than a single, thicker line under the road fill.

[mourner]

We removed composited layers.

[AbelVM]

Any news on getting composite layers bac... like 6 years later?

luma.gl is enabling comp-op blending modes in WebGL and I can't find any performance hit while using it. Blending modes by luma.gl can be tested while within kepler.gl indeed