When ignoring collision boxes outside of visible screen map panning can get ugly

[watbywbarif]

0.44.2 but then reproduced this with official streets-v9 and older 0.43.0:

Steps to Trigger Behavior

1. Use https://api.mapbox.com/styles/v1/mapbox/streets-v9.html?title=true&access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4M29iazA2Z2gycXA4N2pmbDZmangifQ.-g_vE53SD2WrJ6tFX7QHmA#12.1/37.85635/-122.31402
2. Pan map up and down between Oakland and Albany.
3. You can get too many labels drawn that quickly disappear in fraction of second, but it looks ugly

Expected Behavior

I will not post images, as number of labels thins out obviously when tried.

Actual Behavior

I have achieved even worse results with my own data and style:

I guess this is example is overblown because data in .mvt contains too much data for that zoom level, but as this can be reproduced in streets-v9 i am posting it.

When used map.showCollisionBoxes = true it seams to me that collisions are ignored while labels are outside of visible rectangle, but then when panning occurs labels are drawn before collisions are reevaluated.

[anandthakker]

This is due to an intentional tradeoff we made as part of this major overhaul of symbol placement:

mapbox-gl-js/src/symbol/placement.js

Lines 51 to 54 in 13ea16d

	// skipFade = outside viewport, but within CollisionIndex::viewportPadding px of the edge
	// Because these symbols aren't onscreen yet, we can skip the "fade in" animation,
	// and if a subsequent viewport change brings them into view, they'll be fully
	// visible right away.

mapbox-gl-js/src/symbol/placement.js

Line 200 in 13ea16d

this.placements[symbolInstance.crossTileID] = new JointPlacement(placeText, placeIcon, offscreen || bucket.justReloaded);

@nickidlugash @ChrisLoer @ansis am I right in understanding that this behavior is essentially "works as intended"?

[ChrisLoer]

@nickidlugash @ChrisLoer @ansis am I right in understanding that this behavior is essentially "works as intended"?

The "skip fade" logic is actually for items that have been placed/collided, just while they were offscreen. It looks like what @watbywbarif is seeing is features entirely outside the collision index range getting placed, and then sticking around until the next placement happens (it'll happen as they get pulled on screen, but it takes time for them to fade out so you can still see all the overlap for a bit). That's actually a known issue (#5654) that we hadn't gotten around to fixing yet just because it didn't seem like it was too big a problem. Getting this report is a good incentive to re-evaluate that. 😅

Closing as duplicate.