WebGL 1 phase out

[wipfli]

This is a tracking issue to discuss the removal of WebGL 1. At the moment, there are no concrete plans of doing this as far as I understand, but it is good to have a centralized place for the arguments on removing WebGL 1...

[wipfli]

@HarelM you asked previously:

Is there a way you can think of to allow moving the webgl1 code into a plugin somehow leaving the main version using only webgl2 but allowing this plugin to try and "help" in case someone needs webgl1?

I think the answer is no. To really benefit from WebGL 2 one has to write different shaders as far as I understand.

[CommanderStorm]

I think this is the correct link for said feature: https://caniuse.com/webgl2
=> currently 96.1%-98.1% of users have webgl2. The remaining users are in a few small clusters (0.8% IOS mobile, 0.5% IE) and in the weird browsers.

[zhangyiatmicrosoft]

Wait ... I thought webgpu is the future and webgl 1 and 2 are going away anyways ...
Unless webgl2 offers significant perf boost and the migration effort is relatively small, why do we want to spend the extra effort?

[birkskyum]

Yes, webgpu is the future, but we can't sunset webgl until one day when webgpu is sufficiently supported. We currently have superficial webgl2 support, with a webgl1 fallback, and this fallback is kinda blocking us from adopting any webgl2-only features, like layout qualifiers, to begin refactoring of the codebase towards something a little closer to what webgpu will require. Thus dropping webgl1 could narrow the gap and act as a stepping stone towards webgpu. Dropping webgl1 would make the adapter layer that sits on top of webgl and webgpu simpler.

case in point, when the "modularization" refactor started in MapLibre Native to preparing for adding Metal, the first thing that happened was upgrading the OpenGL implementation from OpenGL 2 (~webgl1) to OpenGL 3+ (~webgl2) as it was easier to then abstract over Metal & OpenGL3 than Metal & OpenGL2.

It's of course important that webgl2 is as well supported as webgl1 is for the browser versions we support, so that it doesn't lead to issues for visitors (like anyone using safari on ios <=14), so there is a balance there we always need to gauge.