Godot 4 Beta 17: Browser freezes for minutes when loading a web-exported Godot project in Chrome on macOS

[ghostbutter-games]

Godot version

v4.0-beta17 c400205

System information

Windows 10, GLES3, Chrome Version 109.0.5414.120 (Official Build) (64-bit)

Issue description

When uploading a new project without any content (I tried a simple scene with one 2D sprite and the Godot log graphic), and exporting this as a WebGL build, then loading it on e.g. itch.io, the entire browser freezes on macOS.

On itch.io the setting for SharedArrayBuffer is set, otherwise the project will not even load and shows this error

When loading the project, the Chrome console output shows this error:
Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread onPrintError @ index.js:13991

The error appears, then the entire tab and the rest of the browser freezes completely and becomes unresponsive for about 1-2 minutes.

After the freeze, the game seems to run again, normally.

Important: This freeze only happens on Chrome on my Macbook Pro, running the latest macOS Ventura 13.2 and the latest version of Chrome.

The freezes happens for a very short amount of time on my Windows PC as well, but it's not that noticeable.

Steps to reproduce

• Create a new Godot 4 project with the latest beta 17, either on macOS or on Windows 10 (tested both).
• Add a main scene and a single 2d sprite node in the middle of the screen, just for testing purposes.
• Export the project with the default web export settings
• Upload the project to itch.io and load it
• Encounter the freeze

Minimal reproduction project

This can be reproduced by playing it here: https://ghostbutter.itch.io/test-godot-freeze?secret=wK5roG3DyBXpWjStHef5yf98

[Zireael07]

Does the freeze happen on other browsers/platforms? If not, it's likely the shaders crosscompiling to ANGLE...

[ghostbutter-games]

Does the freeze happen on other browsers/platforms? If not, it's likely the shaders crosscompiling to ANGLE...

The freeze barely happens on Windows/Chrome, it's only 1-2 seconds of noticeable freeze, compared to 1-2 minutes of unresponsive browser on macOS.

Unfortunately this makes current Godot WebGL games basically unplayable on macOS/Chrome.
Would be really appreciated if this could be fixed, if at all possible.

[Calinou]

Related to #70691.

This is expected due to ANGLE making shader compilation very slow. There's no way to work around this issue, and is one of the reasons we recommend sticking to 3.x for web projects currently.

[ghostbutter-games]

This is expected due to ANGLE making shader compilation very slow. There's no way to work around this issue, and is one of the reasons we recommend sticking to 3.x for web projects currently.

That's unfortunate since I really need a feature that's only in 4.X, not in 3.X, so that's not an option for me.

I am also confused why this is not an urgent fix before the release of 4.0?

The way I see it, right now there is no way to make functioning web exports with Godot 4, which basically means that Godot can't really be used for game jams anymore.
Web exports are really important for game jam visibility (download-only game jam titles get wayyy less ratings)

Also: Is it even 100% clear that this is what's causing this?

The console error Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread onPrintError @ index.js:13991 seems to be quite relevant as well? Does this have nothing to do with it?

[Calinou]

I am also confused why this is not an urgent fix before the release of 4.0?

We can't fix it – ANGLE is very slow at compiling shaders, because it insists on doing strict validation of every compiled shader. Godot has a full-featured 3D rendering engine, while most HTML5 ports that start fast don't use WebAssembly, use heavily stripped down renderers, or are ports of late 90s/early 2000s games.

This is made worse by the fact that Chrome insists on using ANGLE even on platforms where it's not required. Windows still supports OpenGL to this day 🙂
You can bypass this with a command line argument last time I checked, but it's not even an option in chrome://flags.

The console error Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread onPrintError @ index.js:13991 seems to be quite relevant as well? Does this have nothing to do with it?

This message is a consequence of shader compilation, which can't be made asynchronous on HTML5. Therefore, it needs to block the main thread. The message is clearly written with non-game applications in mind – those that don't use WebGL and generally not WebAssembly either 🙂

[ghostbutter-games]

@Calinou Thanks for the detailed explanation! :)

But just to clarify: This means that - in the foreseeable future - I won't be able to make web games with Godot 4.X that run on macOS/Chrome? This directly affects my next project which I was about to plan making in Godot, unfortunately.

[Byteron]

but it works in Godot 3, so there is a way to make it work.
Why would Godot 4 not be able to do the same thing?
I would understand it if we were talking about the Vulkan renderer.
But we're talking about the compatibility (OpenGL) renderer, which already worked fine in HTML Exports in 3.5.

[lostminds]

Unfortunately it's not just a Chrome issue. Testing 4.0b17 web exports now: In Safari on macOS 13 the loading bar finishes but then you get a spinning white things that just stays indefinitely as far as I can tell. In Firefox on macOS 13 the progress bar gets stuck at about 95% for 10+minutes before surprisingly starting the game.

In both these cases I think we can assume any normal player would just assume it was broken and give up. It would be great if this could be fixed somehow so Godot 4 web builds would work on macOS as well.

[Calinou]

But just to clarify: This means that - in the foreseeable future - I won't be able to make web games with Godot 4.X that run on macOS/Chrome?

It's possible that Godot 4.x will eventually run well on HTML5, but not before 4.1. See https://godotengine.org/article/release-management-4-0-and-beyond/.

but it works in Godot 3, so there is a way to make it work.

Godot 3.x's GLES3 renderer has a lot of issues on HTML5, including slow shader compilation in Chromium-based browsers. You need to use GLES2 to get a good experience, which is a far more limited renderer (that doesn't even use WebGL 2.0).

Godot 4.0's OpenGL renderer was rewritten from scratch, using an approach similar to GLES2 but with GLES3 compatibility requirements. The approach is however not identical – for instance, single-pass lighting is now used, and that may impact shader compilation times. Multi-pass lighting scales poorly as soon as you have more than 1 light, which is why single-pass lighting is now used.

In both these cases I think we can assume any normal player would just assume it was broken and give up. It would be great if this could be fixed somehow so Godot 4 web builds would work on macOS as well.

Please keep the discussion about macOS in #67949.

[ghostbutter-games]

Please keep the discussion about macOS in #67949.

It is definitely only a macOS issue from what I can see. Windows works fine for me on Chrome.
Firefox on Windows does not even load, though: Error The following features required to run Godot projects on the Web are missing: Cross Origin Isolation - Check web server configuration (send correct headers) SharedArrayBuffer - Check web server configuration (send correct headers)

Overall, Web exports seem to be quite broken as of now, which is saddening because I always considered it one of Godot's huge strengths as my go-to gamejam engine.

[clayjohn]

This is a duplicate of #70691

This indeed looks like a shader compilation issue. Likely it is due to ANGLE on chrome being very slow. We are doing some work on ANGLE for desktop macOS (to alleviate bad drivers) and we seem to have a solution there to the slow shader compiles. If we are lucky, we may be able to enable similar optimizations for web exports.

I also have a few other ideas to decrease shader compilation time in the gl_compatibility renderer generally, but will not have time to work on them until after 4.0 is out.

Closing in favour of #70691