fix: tile renderer recovering the wrong camera position on globe

[Alchez]

Related Issues

• fix: FPS drop under globe projection with large pitch #7851: same root cause, different fix
• Fix terrain tile detail near a pitched camera (#4703) #8049: same function, restructures createCalculateTileZoomFunction instead
• Tile organization should depend on camera position only, not on camera orientation #8057: this PR applies part of the premise to only use the camera position as is

Problem

On the globe projection, a zoom is decided per tile (after zoom level is > 4) based on the distance between the camera and tile. But sometimes the camera's location is incorrectly computed, which causes tiles for that camera to render instead.

Cause

• The tile renderer (coveringTiles) is trying to get the camera's (x, y) to decide which tiles to request
• It does this by going to the screen and coming back:
  1. computing the screen pixel for the ground right below the camera if the map was flat (via getCameraPoint())
  2. asking the projection what that pixel represents on the map (via screenPointToMercatorCoordinate())
• In most cases, like all of mercator and 0-pitch globe projections, (i) and (ii) agree on where the ground beneath the camera is.
• The problem is only for pitched globe projections, where (ii)'s returned value is offset from the actual ground below the camera, and so a different camera is assumed.

Proposed Solution

• Don't go to the screen, and instead ask the transform for the camera directly. Since that doesn't involve the projection, it doesn't matter if it's a mercator or globe.
• getCameraLngLat already computes the camera this way, but instead of a long-lat, we want the coordinate instead. getCameraLngLat has been restructured to call the transform as well.

Reproduction

JSFiddle: https://jsfiddle.net/auqdp6mk/5/

• Resize the output screen to view the different canvas sizes reporting different rendered tile count. The worst one I saw was a z5 camera rendering z9 tiles.
• Moving back and forth between the threshold values should regenerate the wrong number of tiles, and show a drop in FPS.
• Trying to interact with the globe after render can also show jank based on how many levels it needs to recover from (z9 is worst).

Benchmarks

arm	before (hz)	after (hz)	ratio
mercator	193.86	198.43	1.02×
mercator pitched	112.27	114.13	1.02×
globe at 0 pitch	55.01	61.09	1.11×
globe pitched	39.91	34.62	0.87×

The benchmarks are showing correctness instead of a perf gain.

• The top three results are all at pitch 0, so the delta is only the cost of the call
• A pitched globe reports slower only because it's actually rendering the correct number of tiles (not a regression)

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Add an entry to CHANGELOG.md under the ## main section.
• Confirm you have read our AI policy here.

Assisted-By: Claude Opus 5

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.91%. Comparing base (1275d68) to head (6e728e2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8187      +/-   ##
==========================================
- Coverage   93.91%   93.91%   -0.01%     
==========================================
  Files         290      290              
  Lines       24918    24918              
  Branches     6576     6576              
==========================================
- Hits        23402    23401       -1     
- Misses       1516     1517       +1     

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[HarelM]

Thanks for taking the time to open this PR!
I've added a few comments.

[HarelM]

Can you update the initial post with a problem description and a proposed fix (solution explanation). Please make it short.
I've read the code changes but I don't understand why they should solve the problem. So this bit is still not clear from all the text that was written as part of this PR. Sorry...

[Alchez]

@HarelM no worries, it's slightly hard to wrap my head around it too. I've updated the description, can you see if that helps? I couldn't shorten it too much, so I've atleast tried to use sections to separate the text.

[HarelM]

Thanks for the write-up, it helps to understand.
Is this change somehow related to the following or are they orthogonal?

• perf: replace the terrain coords framebuffer picking with a CPU raycast #8158

[HarelM]

I think should indicate what it does, but not in a negative form compared to a different method.

It's not clear what's the difference between this on and getCameraPoint and why not use the other one, or why not change the logic of the other one. The explanation should be part of the PR initial post those, not part of this comment.

[HarelM]

consider renaming this variable to better indicate what it holds.

[HarelM]

how is "refined" related to covering tiles algorithm? I'm a bit confused by this test description.

[HarelM]

Are all the test here really needed? You changed a method "outside" the covering tiles method mostly, I would expect to see more tests there instead of here...?