Godot-proposals: Drop support for non-WebGL 2 web browsers (Apple Safari) for 4.0

[aaronfranke]

Describe the project you are working on:

Applies to any web game made with Godot.

Describe the problem or limitation you are having in your project:

Having to support WebGL 1 for web games requires having a GLES 2.0 backend, which significantly burdens Godot, see #877. The only popular non-WebGL 2 browser is Apple Safari.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

The way I see it, Safari users fall into two categories: Mac users and iPhone users.

• Mac users can either download Chrome or Firefox to play Godot web games, or they could also download a version of the game compiled for Mac.

• iPhone users can download apps instead of playing web games.

Therefore, from what I can see, this proposal would not actually prevent anyone from playing games, and would not prevent game developers from supporting macOS or iOS. If Godot requires WebGL 2, that's not "dropping support for apple devices" as @clayjohn puts it.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

The way this proposal will work is that Godot 4.0 drops support for browsers that don't support at least WebGL 2. This means Godot 4.0 will run on any version of Chrome or Firefox from 2017 or later.

• It is possible that Apple will support WebGL 2 before 4.0 comes out, in which case Safari would be supported in 4.0 on release. The purpose of this proposal is not to spite Apple. The purpose of this proposal is to not let Godot be held back by Apple refusing to adopt new standards. If Safari supports WebGL 2, then Godot 4.0 will run on Safari. If not, then it won't. IMO, if Apple can't support web standards that have existed for 5 years, that's on them.

  • EDIT: Apple will soon support WebGL 2 as per clayjohn's comment below, so the above is true.

• It's also completely feasible that Apple will deprecate WebGL 1, since they have already depreated OpenGL for desktop apps. If this happens, any effort to support Safari by supporting WebGL 1 will be in vain and completely pointless.

The only future where supporting WebGL 1 has benefits is one where Apple does nothing, and remember there are also still drawbacks to supporting such an old API (see #877).

If this enhancement will not be used often, can it be worked around with a few lines of script?:

No, it can't, it's about rendering.

Is there a reason why this should be core and not an add-on in the asset library?:

Yes, it's about rendering.

[Galomortal47]

WebGL is a good back up if apple decides to break compatibility with MoltenVK

[aaronfranke]

I don't see how it is. For one, you'd still need a way to run native apps, so the only option at that point would be Metal itself. For another, it seems much more likely that Apple drops WebGL than MoltenVK.

[Lexpartizan]

Is it worth providing comfort to Mac users at your own expense, when Apple specifically makes every effort (abandoning WebGL 2.0 and OpenGL) to make your software not work? In addition, we are not talking about abandoning the platform, but about rejecting support for a single browser.

[Calinou]

Keep in mind browsers on Windows generally rely on ANGLE to convert OpenGL to Direct3D, presumably to work around issues with poor OpenGL implementations in graphics drivers (AMD/Intel).

When you use WebGL 2.0, you're giving more work to ANGLE, which in turn can decrease performance.

[subjectdenied]

there might be use-cases where you want to use a mobile browser explicitly, and godot 3d-engine-capabilities in it, especially to not have to publish a non-game app to one of the stores out there. killing webgl1 (and therefore apple mobile devices support) would mean godot may not be an option at all anymore for these cross-platform mobile browsers use-cases - unless godot 4.0 comes with webgpu support that i guess apple could support in the future in mobile safari

[fab918]

I'm sorry, but the argument of "keep supporting all the hardware" seems to me very dangerous, that's reminds me how the internet has suffered to support IE.

We talk about an engine that will probably release in 2021, but already now they are nearly 90% of the desktop computers already support WebGPL2, the 10% remaining can just use a decent browser. For mobile they are nearly 75%. Plus, the main use case is for game jammers (for almost all other use cases, you will prefer native build)

Considering this, it's not reasonable to loose precious dev time (there are >5000 issues right now with real use cases) or limit features for nearly no one or niche usages. It seems to me to be __a luxury that Godot must avoid__, especially during his growing phase. Besides, that's a conversation we will have again about GLES2-3 in not a long time, when even a 35$ computer will be able to support Vulkan. It is not possible to please everyone, you must try to please as much as possible and think in the best interest of the engine.

Notes:

• I only talk about this argument since I don't understand all the technical implications as well as if to bet on WebGPU is a better move.
• They already proposed to make 3.2 an LTS version, so they can both live at the same time.

[Calinou]

For mobile they are nearly 75%, and again, IOS user (like me) can use chrome. Plus, the main use cases are for game jammers.

All browsers on iOS use the same WebView, which is Safari's. Chrome on iOS is just a frontend to that WebView, like Firefox on iOS.

[fab918]

@Calinou Thanks, I updated the post.

[vagrantG]

I don't know how much different the work to do the GLES 2 -> WebGL conversion to the GLES3 -> WebGL 2 one would be, probably not a lot different? (more stuff for the second but still the idea is not to support everything GLES 3 introduced, isn't it?).
Implementing both is less an issue, probably, than testing/supporting 4 target platforms, each of one splitting in basically multiple operating systems implementations with their own caveats/bugs (video drivers, web browser engines, etc). Unless crippling even more what you can do in Godot it's a lot of effort for something "lower end" compared to Vulkan stuff, and I'm not really sure about how much work supporting correctly this last technology will be. For example, will MoltenVK have any caveats one can see only when working on it? I don't see having to create a Metal renderer but maybe workarounds, some further development to that wrapper could be needed for an all purpose game engine. Also i think Vulkan on Android is a bit of an unknown thing in terms of effort to support it (bugs, speed, etc).
In the end i think it's good to support as much stuff as possible (if it makes sense) but hopefully the priority is to have a somehow stable Vulkan implementation as soon as possible, then work on the rest so that people could start test that, provide feeback, bug reports and so on.
Only with real test cases one can know the entity of things to do, take the situation with GL ES3 before, it can happen with Vulkan desktop/mobile, WEBGL/WEBGL2, etc.

[clayjohn]

Update for everyone here.

Apple seems to be adding support for WebGL 2.0 through Angle. Angle is also adding better support for Metal. https://bugs.webkit.org/show_bug.cgi?id=126404

Safari already allows WebGL 2.0 through the use of the "experimental" features flag.

For some nice up to date data see, https://caniuse.com/#feat=webgl2

This means all major browsers now support WebGl 2 (or will by the time 4.0 releases).

Accordingly, this proposal is now moot. There will be no need to drop support for Safari. However, it does impact our original discussion regarding GLES2 or GLES3 which is tracked at https://github.com/godotengine/godot-proposals/issues/877