Fix #10763

[karimnaaji]

Fixes #10763 "Map flickers when optimizeForTerrain is disabled, fog is enabled, and a GeoJSON layer is present"

This flickering issue was visible in draw order priority mode, as we split terrain rendering in interleaved render batches between draped/non-draped layers. Currently, fog is applied without considering alpha in terrain_raster.fragment.glsl, and this works when terrain is rendered as a single draw call, but not when we split terrain rendering in several batches and compositing is required.

In the example provided in #10763 , we were rendering fog as many times as we had render batches without correct compositing (e.g. alpha blended), which led to various rendering artifacts when any of these batch had empty space in the tile, refer below with the overly saturated render due to multiple pass of fog applied:

The issue is fixed by accounting for alpha in fog in the draw terrain raster pass.

This PR also simplifies some of logic no longer required by removing unnecessary forceRenderCached and checks against options.zooming || options.moving || options.rotating to have consistent code path on still frames.

cc @jczaplew

changelog: <changelog>Fix a bug where the map flickers with fog when optimizeForTerrain is disabled</changelog>

[jczaplew]

Thank you for such a quick remedy @karimnaaji!

[rreusser]

Looks good. Thanks for the additional cleanup! I just had a small background question about the render cache, but nothing blocking from my point of view. 👏

[rreusser]

Does this logic still exist, just elsewhere? If so, I didn't succeed in tracking it down.

[karimnaaji]

Only the logic for this._invalidateRenderCache is kept. The rest is not necessary anymore and adds complexity to the number of possible code paths, it's a reason why the flicker is only visible during moving frames in #10763.

To provide some context, we launched v2 having two terrain render modes being fairly implicit:

• One render mode using the render cache during interactive frames, not preserving draw order
• One render mode using interleaved draw order otherwise (no caching even for large draped sequences)

The reason being that interleaved rendering was too expensive and honoring draw order on still fames was a fine workaround. The issue with this approach is that still and moving fames were not rendering layers in the same order, leading to noticeable differences when the user stopped moving the camera for example.

In #10258, we moved away from this behavior to have an explicit opt-in render mode with optimizerForTerrain, allowing that decision to be based on the needs of the user depending on whether draw order is important, instead of being implicit to the renderer.

In draw order priority, we still do our best to identify sequences of draped batches to render them cached. Now, this particular check 'options.zooming || options.moving || options.rotating' is what determines still vs moving frames, but we can simply render cache always as it doesn't have any effect anymore: with or without draw order priority we are always rendering the same frames once the render mode choice is made.