WebGL 2 status

[Brian Dodd]

I'm putting together a OpenGL based framework that can be built to target either desktop or WebGl via emscripten. Couple of questions -

First, the emscripten docs talk about targeting either a 'WebGl friendly subset' of OpenGL ES by using the system/include/GLES2 headers or 'OpenGL ES 2.0' emulation by setting the '-s FULL_ES2=1' compiler flag. There are also a set of GLES 3.0 headers in system/include/GLES3, but I can't seem to find a good description about the current status of this code. Is it safe to target emscripten to GLES 3.0 at this point, or is this still a work in progress? If I target GLES3, will this automatically invoke WebGl 2 in the browser? What problems might I encounter? (BTW, I'm currently using a GLFW wrapper).

Second, If I do target GLES3/WebGL2, is there any way to gracefully fallback to WebGL 1 if it turns out that the browser doesn't yet support WebGL 2? I'm guessing that this would probably involve some sort of bootstrap check that would determine feature support and then either pull in a GLES2 or GLES3 targeted main application. What is the best way to test for WebGL support before loading my script?

Going into this I was hoping that things were far enough along so that I could just target WebGL 2 exclusively, but it seems like we're once again in an awkward transition phase. *sigh*

Thanks for any insight!

Brian

[Jukka Jylänki]

2017-07-14 10:42 GMT+03:00 Brian Dodd <bdod...@gmail.com>:
> I'm putting together a OpenGL based framework that can be built to target
> either desktop or WebGl via emscripten. Couple of questions -
>
> First, the emscripten docs talk about targeting either a 'WebGl friendly
> subset' of OpenGL ES by using the system/include/GLES2 headers or 'OpenGL ES
> 2.0' emulation by setting the '-s FULL_ES2=1' compiler flag. There are also
> a set of GLES 3.0 headers in system/include/GLES3, but I can't seem to find
> a good description about the current status of this code. Is it safe to
> target emscripten to GLES 3.0 at this point, or is this still a work in
> progress?

The support for WebGL2/GLES3.0 should be complete and mature at this
point, with no known bugs.

> If I target GLES3, will this automatically invoke WebGl 2 in the
> browser?

Yes and no. This depends on the GL context initialization API you use.
To enable WebGL2/GLES3, build with -s USE_WEBGL2=1. For Emscripten's
html5.h GL context creation API, this linker flag means that you will
be able to choose to initialize either WebGL 1 or 2, whichever you
need. For context creation APIs that allow initialization without
specifying desired GL context version up front, this linker flag will
default to WebGL 2 instead of WebGL 1.

> What problems might I encounter? (BTW, I'm currently using a GLFW
> wrapper).

I believe currently GLFW is one of those APIs that doesn't allow
expressing which GL context version to initialize at glfwCreateWindow
(or version selection has not been hooked up), so it might be that
USE_WEBGL2=1 will mean fixed WebGL 2.0, and USE_WEBGL2=0 will mean
fixed WebGL 1.0. If GLFW has an API field to choose context version,
feel free to submit a PR to hook into that.

>
> Second, If I do target GLES3/WebGL2, is there any way to gracefully fallback
> to WebGL 1 if it turns out that the browser doesn't yet support WebGL 2?

This is easiest with the #include <emscripten/html5.h>
emscripten_webgl_create_context() function, to which you can pass
majorVersion == 2 to init WebGL 2.0, and the function will return 0 if
WebGL 2 is not supported. You can then reinitialize with majorVersion
== 1 to init WebGL 1 as fallback. The Epic Games and Mozilla joint
WebAssembly + WebGL 2 demo Zen Garden at http://mzl.la/webassemblydemo
does this, i.e. it uses WebGL 2 if available, and falls back to WebGL
1 if not. (taking a perf hit and couple of graphical glitches)

If other APIs (e.g. GLFW) have similar paths they can take to enable
expressing fallbacks, we should make sure to enable this kind of
fallback path in there, though currently might be the case those
haven't been hooked up.

> I'm
> guessing that this would probably involve some sort of bootstrap check that
> would determine feature support and then either pull in a GLES2 or GLES3
> targeted main application. What is the best way to test for WebGL support
> before loading my script?

You can either just go and create the desired context version and see
it come back as unsupported, or you can use a JS code "if (typeof
WebGL2RenderingContext !== 'undefined')" to detect if the browser is
new enough to be aware of WebGL 2 API support. That does not yet
guarantee that the GPU would support it though, and for that the only
way to test is to actually create the context with
"canvas.getContext('webgl2');".

>
> Going into this I was hoping that things were far enough along so that I
> could just target WebGL 2 exclusively, but it seems like we're once again in
> an awkward transition phase. *sigh*
> Thanks for any insight!

If your goal is to ease the transition to support both at the same
time, then the feature https://github.com/kripken/emscripten/pull/4923
might also be useful.

[Brian Dodd]

Thanks for pointing me in the right direction jj. It would be nice if some of that discussion was covered on

http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html.

I'm sure that I'll be back again at some point, but this should keep me busy for awhile!

[Jukka Jylänki]

Sure thing!

Hmm, this was the update we did to cover GLES 3,
https://github.com/kripken/emscripten/pull/5297/files. It's not much,
though I'm not quite sure how to improve specifically. If you have an
idea, feel free to help to revise.

> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.