Unexpected "OpenGL ES 3.0 (WebGL 1.0)" reported by glGetString(GL_VER…

[gkv311]

…SION) #13295

In Safari 14 with experimental WebGL 2.0 disabled, canvas.getContext("webgl2") returns NULL first time.
However calling the same method after creation of WebGL 1.0 context suddenly returns non-NULL context!
This is inconsistent with other browsers and causes Emscripten to misbehave
if context creation routines are called multiple times (with intention to re-use existing context).

[welcome]

Thank you for submitting a pull request! If this is your first PR, make sure to add yourself to AUTHORS.

[kripken]

I don't know much about this stuff, cc @juj @kainino0x

[kainino0x]

This is pretty weird, thanks for the fix! Confirmed I'm seeing the bug on Safari 14.0.3 repro'd with
data:text/html,<canvas%20id=cvs></canvas><script>console.log(cvs.getContext('webgl2'),cvs.getContext('webgl'),cvs.getContext('webgl2'))</script>

cc @kenrussell

[kenrussell]

I don't know what the bug could be. Safari 14's code is already quite old. This problem will be completely resolved in the Safari release in which WebGL 2.0 is enabled by default. cc @grorg

[gkv311]

So... the conclusion is waiting for the next Safari release hopefully fixing the issues?

[kenrussell]

Ah, sorry - I should have looked more deeply into this. I didn't understand what I was looking at.

Unfortunately the bug is still present. It will be masked when WebGL 2.0 is enabled by default in Safari, but fundamentally it's still there.

I've filed and taken https://bugs.webkit.org/show_bug.cgi?id=222758 to fix this. In the interim, Emscripten could work around it by checking (carefully, to avoid exceptions for undefined 'WebGL2RenderingContext') the return type of canvas.getContext() in its JavaScript helper libraries and returning null if it's the wrong type for 'webgl' or 'webgl2', but I realize that's pretty gross.

Sorry again for not understanding earlier what the bug was.

[kainino0x]

That does seem like a more accurate workaround than the one in this PR. IIUC, the current PR just reports back the correct WebGL version (is that right?), but I'm hesitant about that because it would make this return an unexpected value - getting WebGL 1.0 from requesting WebGL 2.0 - that applications probably aren't using but could potentially break on.

I guess the question is whether we just want to fix the reporting, or if we want a real workaround.

[gkv311]

Current PR is located within registerContext function.
The WebGL2RenderingContext check has been actually copied from #if GL_PREINITIALIZED_CONTEXT within createContext function.
So alternative could be moving the code to createContext function which would be more consistent to GL_PREINITIALIZED_CONTEXT behavior. But createContext is a little bit messed up with macros and more difficult to modify for develop unfamiliar with code.

[kainino0x]

@juj hoping you might have thoughts here

[kainino0x]

@kenrussell I just happened to look at the Canvas spec:
https://html.spec.whatwg.org/multipage/canvas.html#dom-canvas-getcontext
and it's actually very unclear whether getContext('webgl'), getContext('webgl2') (or vice versa) should be null or not.

[kenrussell]

@kenrussell I just happened to look at the Canvas spec:
https://html.spec.whatwg.org/multipage/canvas.html#dom-canvas-getcontext
and it's actually very unclear whether getContext('webgl'), getContext('webgl2') (or vice versa) should be null or not.

Yes, I agree completely. Filed KhronosGroup/WebGL#3256 about clarifying this.

[kenrussell]

Per discussion with @juj and @kripken today - I think this isn't the best workaround.

Instead, it would be ideal to filter the results of the getContext call in a JavaScript shim before returning the result to higher levels.

• If the context type is 'webgl2' and the context is a WebGLRenderingContext, return null.
• If the context type is 'webgl' and the context isn't a WebGLRenderingContext, return null. (This avoids problems where WebGL2RenderingContext might not be defined in the window or worker global scope.)
• Otherwise, return the context.

How does this sound as a general approach?

(In addition, we can still have #defines in Emscripten which completely ifdef-out WebGL 2.0 support.)

[juj]

Posted a different fix in #13659 , I'll close this out. @gkv311 if you can test that one and confirm that it works for you, that'd be great!