Investigate WebGL 2.0 support

[KeepItOneHundred]

Chrome and Firefox are both aiming to enable WebGL 2.0 by default in January, so it's probably time for regl to start moving in that direction.

[vorg]

Definitely. Committing to regl with not clear WebGL 2.0 roadmap feels a bit risky.

Related issues:

• Improve comments in core.js and util/codegen.js
• Create pretty printer for generated code

[mikolalysenko]

So I have thought about this a lot and have opinions, but it is going to be a bit long to write it all out (so bear with me here). The short answer though is that for at least the foreseeable future, WebGL 2.0 is not worth the trouble. However, when this situation changes, then I think that the best way forward would be via a separate fork (call it regl2) that supports only WebGL 2.0. Combining both WebGL 1 and 2 in the same library seems to me like a really bad technical decision and is likely to create massive cruft and bloat without really doing a good job of wrapping either.

I'll elaborate on these points in a follow up reply.

[mikolalysenko]

WebGL 2.0 is not a sound technology investment today

WebGL 2.0 does not provide anything you can't do in WebGL 1.0

The best argument against WebGL 2 is that it is unnecessary. You can implement any WebGL 2 effect using WebGL 1 (with the appropriate extensions). For example, transform feedback can be hacked with combination of vertex shader texture reads from framebuffer objects. Other features like instancing, floating point textures and multiple render targets are available in WebGL 1 via extensions, and if they are not supported then it is also unlikely that WebGL 2 would be supported either. It is true that WebGL 2 makes all of the above more convenient, but at the end of the day you don't really need it.

WebGL 2.0 is not backwards compatible

WebGL 2 changes many APIs in ways which are both large and small. One of the biggest problems is changing the version of ESSL which effectively breaks shader compatibility. This means that if you want to support WebGL 2 and WebGL 1, then you have to effectively write two versions of your renderer and ship both of them (including two sets of shaders and two different pipelines). This sucks and requires massive duplication of work.

Support for WebGL 2 is bad will stay that way for a long time (especially on mobile)

WebGL 2.0 is a wrapper over OpenGL ES 3.0, which is not quite standard on all mobile devices. Even today, vendors are still shipping new phones max GLES 2.0 support. Looking back at the historically slow roll out of WebGL 1 onto iOS (it took Apple years to finally ship it), I am not optimistic that WebGL 2 will get above 30% adoption for years. While WebGL 2 is usable for proof-of-concept and one-off installation work today, it is unreasonable to expect that most web users would be able to run it. This defeats one of the greatest benefits of the web, which is the accessibility and ease of use.

Infrastructure for WebGL 2.0 is immature

Finally, we are still in the early days of WebGL 2.0. This means that there are still many opportunities, but the going is much harder. We still don't have a headless render for WebGL 2 or any system for working with it, and systems like glslify will have to be updated. Taking all this into account, it more than counteracts any convenience improvements in WebGL 2, so if you are doing it expect to spend more time and development effort on whatever you are trying to build.

[mikolalysenko]

The case for patience and forking regl to WebGL 2

There is no way to unify both WebGL 1 and WebGL 2

First, there is no unifying abstraction over the two APIs. If you are using transform feedback, then you have to write a completely different set of shaders and techniques than if you did ping-ponging/FBO hacking. As a result the underlying WebGL version always leaks into the user space. So whatever pathways and code generation regl uses will have to be specialized into separate versions for WebGL 1 and WebGL 2.

Code bloat and scope creep

Having two separate pathways means that we'll have to ship more code on the client, bloating the size of the library and leading to scope creep. The best way to fight this is to take a disciplined stance early on and say no to unnecessary features. Long term, this will help keep maintenance costs down and keep the library small, efficient and correct.

Time to learn

Finally, if we wait a couple of months to a year for WebGL 2 to settle before forking, then we'll also have more time to see how well regl works and learn from it. The library is still young and the best practices for how to work with this regl haven't completely been developed. Taking some time to let things settle down and reflect on how it could be improved means that when we do finally get around to making a regl for WebGL 2, we can actually make real qualitative improvements. If we jump the gun and start on it right now, then it is like that whatever mistakes exist in regl (which we have not yet discovered) will be repeated.

[vorg]

Thanks for the reply. I agree that fork for v2 is the way to go and given the state of webgl2 on Apple platforms we have 1-2 years to go.. Didn't know that ES 3.0 situation on mobile is also that bad.

As for the benefits I'm mostly looking forward to Uniform Buffers for my fat PBR shaders.

[gregtatum]

One other thing to note with working with only WebGL 1, is that extensions don't seem to be supported by ANGLE, so things like headless-gl will fail for doing things from node and the command line. I ran into this issue this week.

[transitive-bullshit]

@mikolalysenko agreed with all of your points, though I do feel this question will come up increasingly as devs become interested in the latest & greatest (even if it's not necessary). I'd suggest adding a small note to the main README pointing to this discussion and affirming that regl specifically targets WebGL 1.0.

[mattdesl]

I ended up doing a lot of work trying to get WebGL2 working in ThreeJS for a Mozilla demo. I generally agree with @mikolalysenko that WebGL2 is not mature enough to bother supporting fully.

These are my three favourite features so far; the WebGL1 emulations are tricky and lead to some performance or quality loss.

• MSAA render buffers: this means we can use post-processing and MSAA at the same time. In WebGL1 we are stuck with something like FXAA which our designers are not as happy with.
• Transform feedback: something we tested on the Mozilla project was to update an instanced position attribute for a flock of bird geometries with the output of transform feedback.
• Seamless cube maps: This is mainly useful for PBR and variable roughness with prefiltered & mipmapped radiance maps. ThreeJS emulates this with two fetches into a 2D texture atlas with all mipmap levels and cube faces which is less than ideal.

I'd definitely be interested in seeing a fork with some WebGL2 work. Even if Chrome is the only browser that supports it over the next 2 years, there are many applications built in Electron (e.g. games, image/video/art tools, live art installations and VJing, etc) that would benefit from having a WebGL2-compatible framework.

[quantuminformation]

I think it's reasonable to develop apps that only work for Chrome if the clients deems it acceptable for its users to be told "chrome only". I'm gonna try build a vanilla webgl scrolling road in webgl2 and come back here if its too painful.

[gregtatum]

Chrome-only when Firefox has WebGL 2: 😣

[ghost]

WebGL 2.0 have features, that have no in 1.0. Firstly is double precisions. Also, WebGL 2.0 have bitwise operations, and improved integers support. Yes, lack of compute shader and some packing functions.Yes, have no SSBO.

[mikolalysenko]

Yeah, this will happen. Need to think through all the details but it is on my radar.

[sasha240100]

Hey, guys, has anyone tried to implement regl2 already?

[sasha240100]

@mikolalysenko I’m open to give a try to reimplementing regl with webgl 2 next two weeks. Is there any roadmap with best practices or notes that I can look at?
If there isn’t - let’s create a google docs page and attach to this issue?
Is webgl2 mature enough today?

[mikolalysenko]

I think the situation with WebGL 2 hasn't changed much. Adoption is still around 40%, so I wouldn't actually ship anything with it. The spec seems solid enough we can start building and experimenting but it's still 1-2 years before I'd use it in production.

[TimvanScherpenzeel]

As part of internal feasibility research I've researched WebGL / WebGL2 support on currently popular devices using Browserstack. I agree with you that it is still early days for WebGL2 and there appear to be quite a lot of driver issues that are being fixed. Safari Technology Preview currently ships with WebGL2 behind a flag but this is only half of the spec and doesn't accept the new #version 300 shaders yet.

https://gist.github.com/TimvanScherpenzeel/f8efeeb1dbed38a5c5dc0c29768a0413

[delaneyj]

Just a heads up, WebGL is now at 76.16% adoption. Is there a value where its worth it to regl to guarantee VAO,UBO and NPOT textures?

[chromice]

WebGL2 seems to be very much dead as far as Apple’s platforms are concerned. OpenGL was deprecated and engineers responsible for webkit’s WebGL2 “implementation” are now working on WebGPU, which is a much better API not only in terms of stuff you can do with it (graphics, physics, neural nets, etc.), but also raw performance (no more unnecessary CPU and memory bottlenecks), not achievable in WebGL for architectural reasons. Although it is years away from being production ready and having 99.9% penetration, it is clearly the future.

Which is long way of saying that there will never, ever be a regl2...

And that’s a good thing. Long live regl!

[hrgdavor]

Wow that sucks, as there are performance gains in just switching from weblg to webgl2.

I have created a renderer for openjscad that uses threejs that is 10x faster in render setup for quite few use cases (big objects, many reused geometries).
those are no small numbers, and they make a huge difference from having realtime preview of jscad model to waiting few seconds. Boolean operations in CSG are slow in nature, but is very sad to be slowed down by regl for many simpler models 😞

It is so sad to see such agressive stance against webgl2.

I can force webgl2 but then regle stops me from using extensions that are included in webgl2 like oes_element_index_uint

This just makes me angry, and all I can say is some of you should read a webgl2 tutorial (after claiming it is not backward compatible) 😞
https://webgl2fundamentals.org/webgl/lessons/webgl1-to-webgl2.html

[hrgdavor]

@chromice https://caniuse.com/webgpu not gonna happen . it is 2021 now , and no sign of it.

[zakjan]

From Kronos WebGL + WebGPU July 2021 Meetup, WebGPU 1.0 might ship early 2022. Meanwhile, WebGL2 is supported in iOS 15.

[hrgdavor]

@zakjan thanks for the link and info. It is nice to see where things are be heading.