Closed ansis closed 11 years ago
Good points. I think we should test drawing a layer to a framebuffer and copying over the result; it might actually be relatively fast. This would also allow us to switch to using GL_POINTS
for drawing round line joins, then drawing disconnected line segments on top. This is the way Google does it.
I'll try with framebuffers its probably cleaner and just as fast.
Last week I worked on the other approach. Overall it looks good, but has noticeable defects in some edge cases. There are more draw calls (two for each semi-transparent) but I haven't notice a performance difference.
On a side note, what are your thoughts on using framebuffers to cache rendered tiles for panning?
I implemented this with the framebuffer approach. Seems to be just as fast, and simpler (both conceptually, code, and style-wise), so this seems to be the way to go.
As of 2018, is that still possible ?
@cyrilchapon it is not possible anymore. The framebuffer approach was removed because it turned out to be a performance trap. It was too easy to create slow maps by adding more than a few layers with layer-level opacity.
If I hypothetically have a mvt server and a "dissolved coverage" to show, semi transparently. What would be the best approach then ?
I don't need and don't want the cumulative approach (multiplying features opacity), I literally want to have polygon visually dissolved runtime
Still no solution to this?
also wondering about the status of this -- it would be very useful to manage the transparency of a layer that has overlapping features
EDIT: answering myself https://github.com/mapbox/mapbox-gl-js/issues/4090
Let's say I want to draw a semi-transparent street layer on top of satellite imagery.
If we just change the line opacity it looks something like this: Ideally, we can get rid of the overlapping. I'm seeing two possible approaches.
One approach would be to draw opaque lines to a framebuffer, and then copy them over with a different opacity, but this is probably fairly slow (completely untested).
The second approach would be to use the depth buffer to prevent double drawing. This works, but has some bugs:
There are hairline cracks caused by anti-aliasing where the roads connect. The fragment is not opaque, but the depth buffer still gets written preventing the other line from being drawn there. To avoid this the anti-aliasing would need to be drawn later, separately. During the second draw, most of the fragments would be depth culled, so this shouldn't add a fragment shading cost. This change would also need to be made for #77 to be implemented.
The second problem is round linecaps. See the intersection on the right. The only way I see getting around this is adding something to the datatiles to specify whether a road ends in a junction or dead end. Or drawing linecaps/joins separately might fix this problem.