Bufferless rendering

[anandthakker]

Currently, vector tile buffers are important for rendering in GL because:

• rendered geometry != source geometry: a feature whose source geometry is located within A may be rendered partially or wholly outside of A's bounds, in some neighboring tile B. For example, a line inside A may have a line-width that extends past the boundary into B.
• We draw one tile at a time, and for each tile, we only draw the region within that tile's bounds, using the stencil buffer to mask away anything that would fall outside of it. When we draw tile A, the part of the rendered line that bleeds outside of its boundaries is masked away. Thus, when we draw tile B, we must have access to the geometry of that feature from A so that we can draw the portion of it that falls within B's bounds.

This approach also help us avoid the problem of clipping detection, distinguishing "real" vertices from clipping artifacts. If a line that crossed a tile boundary were clipped hard to its edge, we wouldn't know whether to draw a line cap there or not. This problem can be pretty easily solved if we distinguish real vertices and clipping artifacts in VT3, so the focus of this ticket is on the rendered vs. source geometry issue.

Downsides of the current approach:

• We draw the everything in the tile, including whatever's in the buffer, and then mask away everything in the buffer. This is wasteful.
• We make one draw call per tile, per layer.
• Buffers in vector tiles add up to a lot of duplicated data and therefore cost bandwidth, storage (including offline storage on mobile devices), and memory.

The purpose of this ticket is to track the question: can come up with an approach to rendering that doesn't rely on buffers, using [version 3 of the vector tile spec] as an opportunity to introduce any changes that such an approach might require?

cc @kkaefer @ansis @mourner @jfirebaugh

[anandthakker]

One approach that I think @kkaefer has proposed and that @jfirebaugh and I started investigating recently:

Alter how we divide responsibility between tiles: instead of each tile being responsible for the features that are rendered within its boundaries, each tile would be responsible for the features whose source geometries are located within its boundaries.

This approach has some tricky challenges (dealbreakers?):

• Correct line rendering (or stroked polygon rendering) is quite complicated due to line joins near tile boundaries
• Correct draw order -- see Encoding features that can be “merged” from multiple tiles vector-tile-spec#104 (comment) and Encoding features that can be “merged” from multiple tiles vector-tile-spec#104 (comment)
• Would we still do one draw call per tile? Or would we somehow concatenate the buffers for each tile so that we could do a single draw call? (Note that it'd be more than literally concatenating, since we'd have to translate indices from the index buffers)

Another approach that we've mentioned but not really investigated would be to abandon tile-by-tile layout altogether, which would allow us to reassemble geometries that have been split across tiles... but it's hard to imagine how we could do this with acceptable performance.

[dagjomar]

Is there a hybrid solution possible? Instead of tile-by-tile, is it possible to have performance gains by doing something like combining 4x4 tiles and rendering them as a "single tile" Like a "big virtual" tile?

[mourner]

Looks like we don't have a way forward with this, at least for the nearest year or two. I'm going to close for now and reopen in future in case a glimmer of hope appears for this.