feat: add rasterPixelAlignment map option - #8206
Conversation
|
Thanks for taking the time to open this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8206 +/- ##
==========================================
- Coverage 93.94% 93.94% -0.01%
==========================================
Files 290 290
Lines 24917 24922 +5
Branches 6576 6578 +2
==========================================
+ Hits 23408 23412 +4
- Misses 1509 1510 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Sorry, that was too much text. I've rewritten the description. |
|
Can you share a video? |
|
Video attached above. Yes, I'd call it a bug. The snapping is intentional; the fact that it applies to one family of I picked the flag because it's the one version that provably can't regress anyone — the default |
video_maplibre.mp4
What I ran into. In my own projects I use raster tiles as the basemap, with markers and vector layers (lines) on top. Every time the camera stops moving — end of a pan, end of a
flyTo, end of drag inertia — the basemap and the overlays jump relative to each other by a fraction of a pixel. What you see is the markers and the lines twitching against the map. Short slow drags show it best; inertia makes it happen twice per gesture.Why it happens. Raster layers are drawn with a pixel-grid-aligned projection matrix, but only while the map is idle. Every other layer type always uses the unaligned one.
What this PR does. Adds a
rasterPixelAlignmentmap option, defaulttrue, which is exactly today's behavior. Set it tofalseand raster, hillshade and color-relief layers never snap to the pixel grid, so nothing shifts relative to anything else.claude-opus-5[1m]) via Claude Code to find the code path and draft the tests. I verified all of it and ran the unit, build and render suites locally.