confirm tile draw priority

[incanus]

In working on #115 raster tile crossfading, I wanted to make sure that I understand the current desired intent with drawing tiles, including parent and children tiles for currently un-parsed native zoom tiles. This is important because it affects what textures are on screen when crossfading occurs.

Say we are at the top left of z8. In the best case scenario, we want these tiles to draw:

+-------+-------+
|       |       |
| 8,0,0 | 8,1,0 |
|       |       |
+-------+-------+
|       |       |
| 8,0,1 | 8,1,1 |
|       |       |
+-------+-------+

If all we have for a missing 8,1,1 is one of its child tiles from z9, we instead get this (not to scale):

+-------+---------------+
|       |               |
| 8,0,0 |     8,1,0     |
|       |               |
+-------+-------+-------+
|       |       |       |
| 8,0,1 +-------+-------+
|       |       | 9,3,3 |
+-------+-------+-------+

When 8,1,1 does come in, it's drawn, 9,3,3 is not, and all is good.

On the flip side, if all we have for a missing 8,1,1 is its direct parent tile 7,0,0, what we want is this:

+-------+---------------+
|       |               |
| 8,0,0 |     8,1,0     |
|       |               |
+-------+---------------+
|       |               |
|       |  lower-right  |
| 8,0,1 |  quarter of   |
|       |     7,0,0     |
|       |               |
+-------+---------------+

But instead, we first draw the three z8 tiles (per high zoom sort order front to back), then draw 7,0,0 like this, since this z7 tile is the parent of all four z8 tiles in question:

+-----------------------+
|                       |
|                       |
|                       |
|                       |
|         7,0,0         |
|                       |
|                       |
|                       |
|                       |
+-----------------------+

We don't make any extra draw calls (three native z8 tiles unclobbered + one clipped z7 vs. three native z8 tiles clobbered + one full z7 tile) but we do extra work for unnecessary tile fade animations on the z8 tiles, plus we lose out on the higher resolution available in the clobbered z8 tiles until 8,1,1 finishes coming in.

[incanus]

A practical downside to the current behavior with raster: in this case, I zoomed in quickly and this large tile was available as a (super)parent to draw now:

However, it sat for quite some time until many, many native zoom tiles loaded to replace it fully, as opposed to each of them being able to come in when available (note the current native tile size in the bottom left).

[kkaefer]

We're doing a sort here: https://github.com/mapbox/llmr-native/blob/master/src/map/map.cpp#L416-L421

This used to be correct, but when I switched the drawing order, I missed this. The way we're drawing right now is the following: Draw all opaque elements front to back, then all translucent elements back to front. I suspect when drawing raster tiles, you're not enabling writes to the depth buffer, so when drawing front to back, it thinks there's nothing at the place and draws the z7 tile over the other tiles.

[incanus]

I suspect when drawing raster tiles, you're not enabling writes to the depth buffer

Correct. I think I had ruled this out earlier on as not mattering until we were drawing vector + raster combined, but good call. I will work on this.

[incanus]

Depth buffer gets a little gross here because unlike vector tiles, relevance between tiles matters. On vector, we only care about strata within a tile.

I'm currently thinking of reusing the clip_id since that's sequential and post-desired sort order, getting a total of all tiles being drawn, and passing that total to each tile's painter.render() call so that it knows which stratum it is... but this feels grosser and grosser.

[jfirebaugh]

Closing old ticket; I don't think we know of any serious issues with our current tile priority.