Render tile masks in order

[TimSylvester]

Tile masks were being rendered into the stencil buffer in whatever order they ended up in RenderTiles. When multiple sources are present, this can result in lower-detail tiles blocking higher-detail ones from rendering.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f1098b2) 85.68% compared to head (44fc0f8) 85.69%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1989   +/-   ##
=======================================
  Coverage   85.68%   85.69%           
=======================================
  Files         569      569           
  Lines       28049    28052    +3     
=======================================
+ Hits        24035    24040    +5     
+ Misses       4014     4012    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Bloaty Results 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%    +880  +0.0%    +296    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results/pr-1989-compared-to-main.txt

Compared to d387090 (legacy)

    FILE SIZE        VM SIZE    
 --------------  -------------- 
   +19% +21.6Mi  +400% +23.9Mi    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results/pr-1989-compared-to-legacy.txt

[github-actions]

Bloaty Results (iOS) 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%     +96  [ = ]       0    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results-ios/pr-1989-compared-to-main.txt

[louwers]

This is to fix #1981 right? I am testing with maptiler-planet source from the MapTiler Outdoors style and a custom vector source with a single triangle. This is what is rendering...

this branch

826f17b (commit before 2e489eb)

Prior to Metal project (ios-v5.13.0)

MapLibre GL JS

[TimSylvester]

This is to fix #1981 right?

I recognize the triangle from the Slack discussion, but I didn't see the issue number. Probably it's related, but a separate issue from the "Pastel" style linked there. Is a custom vector source tile-clipped? It doesn't seem like it should participate in the stencil masking at all.

[TimSylvester]

This seems to improve things, and makes sense to me. But looking way back, tiles have always been rendered to the stencil buffer in RenderTiles order which I'm pretty sure hasn't changed.

https://github.com/maplibre/maplibre-native/blob/71f6da27228c6b95ccd0e5d9e7229eba41724012/src/mbgl/renderer/paint_parameters.cpp

So I'm a little worried that I'm totally missing something here. Perhaps the order in which sources are listed matters, and it only worked before if they were in order of increasing max-zoom?

[sjg-wdw]

Might be a good idea to try a bunch of the styles visually and see if there are problems.

[mwilsnd]

One observation I made - clipping masks were rendered during the opaque pass but the raster layer in the pastel style is translucent. That feels like it shouldn't work, since high zoom vector source tiles are possibly being rendered both in front and behind the raster layer. But everything is in the translucent pass. It feels like the most correct solution then would be to detect when visiting a new RenderItem with a different source and re-rendering the clipping mask for that source.

[louwers]

On zoom level >= 14 the behavior is a bit different still (see comment), but this fixes the problem with MapTiler Outdoors.

Let's focus on extending the render tests instead of manual checking.

[TimSylvester]

... detect when visiting a new RenderItem with a different source and re-rendering the clipping mask for that source.

I had been thinking along similar lines. Re-considering what are the correct criteria for rebuilding the mask reminded me that the way we decide that has changed, and that may have been a mistake.

Specifically, a layer reuses the mask if the tiles are a subset of what's there, rather than set equality. If the tiles don't overlap that makes sense, but if there can be overlaps then sometimes a subset should be considered not equivalent.

That was done because we were rebuilding the mask several times per frame in some cases, when some layers didn't produce any data for one tile or another. But that has since changed to account for prefetch tiles, see #1871.