RFC: Deprecate WebGL 1

[mwilsnd]

Following conversations from our monthly meeting, I'm opening this discussion seeking comments from the wider community around the potential impact of finally deprecating WebGL 1. This topic has been discussed at length in the past (and attempted #2653), much of it linking back to the tracking issue for this topic: #3947.

Currently, the developing roadmap for JS is looking towards the adoption of luma.gl instead of creating a custom abstraction. Adopting luma will save a lot of engineering effort and opens the door to easier WebGPU support (#2606). Since luma doesn't support WebGL 1, we'll have to drop support for it in order to move forward with this approach. There are additional perceived benefits to adopting luma, notably easier interaction betwen Maplibre and other web applications which use it. Not to mention, using a production tested library from the start is always appreciated.

On desktop, any driver which claims support for OpenGL 4.3 (released in 2012) also supports OpenGL ES 3.0, and by extension, WebGL 2. In practice, on Windows devices a system must support D3D11. The cutoff for this on the low end seems to be 7th generation Intel HD graphics. The most common of the prior generation, HD Graphics 3000 (2011), seems to only report support for DX feature level 10.1. It may support 11.1 on later versions of Windows, but I haven't been able to verify if that is true or not. Digging into the past for AMD, it would seem even as far back as 2011, such iGPUs have supported DirectX 11. Khronos also reports the compliance of these SKUs with OpenGL 4.4 but it is uncertain if this means browsers actually support these older AMD iGPUs.

On mobile, iOS first saw support for WebGL 2 in iOS 15 (2021)(with performance issues fixed in later versions). Android has generally supported WebGL 2, however a specific version of Chrome for Android which claims first official support has been hard to locate. As a general rule, if an Android device supports OpenGL ES 3.0, it should be capable of WebGL 2 with a recent browser. Notable outliers are mobile devices with banned drivers like the Samsung Galaxy S4 Mini (2013) and other devices using similar Adreno 3xx series GPUs.

In 2022, Khronos group announced an important milestone, support for WebGL 2 in all major browsers. Needless to say, this has taken a long time but we're now a couple years into broad device support for this technology. Even with this important milestone now behind us, the long tail of older supported devices, in particular by large corporate users, cannot be easily ignored.

I'm asking for comments from the community and large corporate users. How will this change impact you? Specifically with mobile devices, what do your user metrics tell you about adoption of WebGL 2-capable devices? Is there still motivation to support older iOS versions (13, 14)? What about on Android? There are options available to explore for potentially impacted users, the most likely being a community supported WebGL 1 feature branch, as was done with Maplibre Native during the OpenGL ES 3.0 upgrade.

[birkskyum]

We recently requested a probe from Bing maps to see what is the status of user session support for webgl2, and this spring it was 94% user sessions that supported it.

That figure wasn't high enough to just make a simple sunset of webgl1 support in that deployment, so another solution is needed, which could be either staying on older version, a compat branch, or conditionally loading a new-or-old version of gl js. Regarding which solution is best there wasn't discussed, it was just to get a status. I don't have confirmation if Bing ever updated to maplibre v5, since there were some concerns around the build size increase resulting from the new globe feature (which isn't currently used there).

[Willjfield]

It's worth seeing if there are any maplibre plugins that would break and trying to notify their developers - I guess just all the contributors to awesome-maplibre would be fine. fwiw, I think it's probably overall a good idea to deprecate webgl1 soon, if not now - just wouldn't want plugin developers to be caught off guard.

[HarelM]

I think most plugins are not using the shaders and webgl stuff, but there might be a few... In any case, if they are maintained they should facilitate for this, if they are not maintained they probably won't change the code anyway, but it's worth trying to reach out nevertheless...

[0xFA11]

I think most plugins are not using the shaders and webgl stuff, but there might be a few... In any case, if they are maintained they should facilitate for this, if they are not maintained they probably won't change the code anyway, but it's worth trying to reach out nevertheless...

+1, to add a bit more: if plugin maintainers somehow choose to upgrade to a new major version (let's say from current v5 to upcoming v6), it should be expected and be OK to have some things break. I also think that most of the plugins are simply not shaders oriented but rather geared more towards additional controls based on maplibre-gl-js APIs.