New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[maplibre] checkerboard rendering regression when interleaved: true
#8602
Comments
@donmccurdy @felixpalmer @Pessimistress any idea what causes this regression? |
I'll try testing tomorrow, but this looks similar to the issues fixed by visgl/luma.gl#2032, just released in luma v9.0.2. |
Seems not to have been resolved by the earlier fix. Possibly a depth buffer issue. I've started a branch and copied the repro case into an example for testing... https://github.com/visgl/deck.gl/compare/donmccurdy/fix-maplibre-interleave ... will see what I can find on a fix there! |
Hey @birkskyum and @HarelM, we're so far unable to track down the cause of this rendering issue with deck v9 and maplibre. We aren't noticing it with other base maps. Do know anyone who could help us resolve this? Your help is much appreciated! |
Can you clarify what the issue is? |
Did you notice the checkerboard rendering artifacts in the video or Codesandbox? That only seems to happen in Maplibre. I'll try Maplibre 4. Also to clarify, interleaved rendering (shared context) works without artifacts in Mapbox (and Google maps) but not Maplibre. |
The CodeSandbox repro is already on v4, and it's still showing the error, so it's not fixed yet. Hmm, my first intuition was it's some z-fighting, similar to the flickering in the MVTLayer on zoom, so a negligible offset on either side might potentially be able to resolve it until WebGPU comes to the rescue. |
I'm guessing it is related to "fighting z order", but my expertise here are limited when it comes to webgl context stuff... |
Might be worth checking how we can increase the depth buffer precision, and what it'll cost. |
For the issue introduced in 9.0.0-beta.6 This could very well come as a result of bumping luma.gl from 9.0.0-beta.4 to 9.0.0-beta.6, which cuts away webgl1 support entirely, as mentioned here. It's maybe not the only thing, but I do see a mention to "Use device.createTexture instead of WEBGLRenderBuffer". I believe MapLibre LG JS still use the WEBGLRenderBuffer here: Updating these places, potentially by introducing more conditional webgl1/2 logic, or it might help to simply go webgl2-only like deck.gl, which we had mixed results trying last May with the v3 release. |
Good observation, worth some thought... But I can't think of a reason why creating and binding a There is no deep motivation behind the renderbuffer removal in v9. It just didn't seem worth the trouble to expose Renderbuffers through the luma.gl v9 Texture API - since it seems that textures can be used in all cases that required Renderbuffers in WebGL 1, and I could not find clear information stating that there are convincing perf advantages to renderbuffers. |
I'm also having this issue via mapbox-gl when interleaving since updating to deckgl v9/mapbox v3 |
Repro works when using mapbox-gl with a mapbox basemap: Codesandbox |
|
These layers (e.g. roads) are native basemap layers though, so I don't think there is a PolygonLayer to apply props to. Maybe there's a maplibre equivalent. I do agree it looks like z-fighting. |
Just noting that the problem is present in both mapboxgl v2 and v3, but not in deck 8.9. |
Sorry, I meant the ScatterplotLayer. And to be clear, I was talking about making a change in the linked codesandbox. I was going to try to but it seemed read-only.
|
Now that luma can enforce WebGL2 on WebGL1 libraries, I'm attempting to see how mapboxgl v1 and maplibre v2 fair in this codesandbox. However, I haven't figured out how to access |
@chrisgervang , that's interesting - I can think of some places that likely will be problematic as a result of some missing webgl2 extensions in maplibre v2. Cases like the maplibre heatmap layer come to mind, but I'm curious to see how it handles it. |
I assume you are referring to the fact that WebGL2 contexts are not allowed to support WebGL1 extensions that offer functionality that is built-in to WebGL2. It would probably not be hard to make shims for those extensions if you had a list. After all the reason they are removed is that the functionality is already supported in the core, so we just need to override |
All conditional loading of extensions is contained here: And a single VAO check here: |
I looked and realized your code handles both WebGL1 and WebGL2 with dynamic checks so you should not have any issues as far as I can tell, even if we force feed you a WebGL2 context. |
It does have webgl1/2 compat from v3 and forward, but it didn't have that in maplibre gl js v2 which @chrisgervang wanted to try, so comparing these two versions can give an idea what a shim should add. |
I'm noticing a rendering issue in Maplibre GL JS when deck renders into its WebGL context (
interleaved: true
). The tiles aren't rendering correctly, they "checkerboard" while navigating.This issue appears to only effect Maplibre v3 & Deck v9. I've tested and found no issue with Mapbox GL JS v3 & Deck v9, or with either basemap lib in Deck v8.9. Note that I can't test Maplibre v2 or v1 since Deck v9 requires WebGL2 for interleave.
Reproduction: https://codesandbox.io/p/sandbox/deck-v9-maplibre-interleave-repro-8602-lzx4z8?file=%2Findex.html%3A8%2C54
interleaved.mp4
Originally posted by @chrisgervang in #8551 (comment)
The text was updated successfully, but these errors were encountered: