Labels flicker at high zoom, especially for pitched map views

[asheemmamoowala]

The flicker/blink is more pronounced on pitched views.
When zooming in beyond z18, labels take >500ms to re-appear in some cases.

The trace shows symbol re-projection taking very long on the over-zoomed tile.

/cc @ChrisLoer

[ChrisLoer]

An overzoomed tile has a lot more line labels than normal because they're generated for the whole tile even though the viewport is only showing a small portion of the tile. But that shouldn't slow down reprojectLineLabels that much because the 'isVisible' test should filter almost all of them out pretty quickly (although it does have to do a projection for every anchor point, it still doesn't seem like it would degenerate that far). It should be pretty straightforward to check that (1) the filtering is working and (2) the filtering isn't taking too long.

If the filtering is working well, the next place I'd look is to see if you're running into a variant of mapbox/mapbox-gl-js#5112. Although that bug was about the rendering being incorrect, it wouldn't be too surprising if the w overflow caused some code to go bonkers and get more expensive as well. That type of problem would only happen in pitched views, so if you saw the problem in unpitched views as well, there'd probably be some other cause.

reprojectLineLabels is a synchronous part of rendering, so if it's taking a long time, I think the symptom would be "low frame rates" or "map pauses/stutters", rather than "label flicker" (although slow frame rate could accentuate the effect of label flicker caused by something else).

/cc @ansis

[jfirebaugh]

The flickering might be #7026.

[asheemmamoowala]

Thanks for background @ChrisLoer.

I've run a few time profiles, and don't see anything jump out yet.
Notes on what I've found so far (and some of these may have been obvious):

• The Placement Throttler is triggering a placement at the end of the zoom animation. But lowering the throttle frequency has no impact.
• On over-zoomed tiles, the number of placed symbols (without collisions) continues to grow. This linearly increases the running time for GeometryTileWorker::attemptPlacement
• Given that more symbols get placed in the tile, the running time of reprojectLineLabels also increases and corresponding number of vertices in dynamicVertexArray grows - even though most are hidden by the isVisible() check

The result of this is that at the end of a zoom animation (using double tap, for example), the second to last frame is drawn without symbols, and the last frame takes longer to be prepared and reprojected before is is rendered.

While there is some similarity to #7026, on the over-zoomed tiles, there are no new tiles being requested in this case. It boils down to the placement taking too long and one or more frames being rendered while symbols are still being placed.

From printf statements (in debug, so numbers are bigger), when zoooming from z19 to z20 in a section of downtown Chicago (Tile 16/16816/24356):

• Time between second to last and last frame >500ms - this is the time for placement to be completed
• Time for attemptPlacement increases from ~250ms to 500+ms
• Number of placed symbols for road-label-large goes from 68 to 158 and a corresponding increase in the size of dynamicVertexArray from 3k to 7.5k

What needs investigation is whether we can keep around previous over-zoomed tile and render it while the next zoom level tile is still being placed.

[ChrisLoer]

We should fix this with #10103, or at least change the problems we have.

[ChrisLoer]

Fixed with #10436: placement is now tied to the viewport, so overzooming doesn't make placement significantly more expensive (there are still some extra costs). Also, the tile loading/rendering architecture has changed so that pathologically slow placement won't cause flicker (instead, it would cause very slow frame rates).