-
-
Notifications
You must be signed in to change notification settings - Fork 20.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Godot 4 Beta 17: Browser freezes for minutes when loading a web-exported Godot project in Chrome on macOS #72584
Comments
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. |
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. |
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. Also: Is it even 100% clear that this is what's causing this? The console error |
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 🙂
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 🙂 |
@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. |
but it works in Godot 3, so there is a way to make it work. |
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. |
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/.
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.
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. 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. |
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 |
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 errorWhen 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
Minimal reproduction project
This can be reproduced by playing it here: https://ghostbutter.itch.io/test-godot-freeze?secret=wK5roG3DyBXpWjStHef5yf98
The text was updated successfully, but these errors were encountered: