godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
87.1k stars 19.57k forks source link

[GLES3] HTML5 exports cause Chrome to lock up for 30 seconds or so #56670

Open tavurth opened 2 years ago

tavurth commented 2 years ago

Godot version

3.4.2

System information

OSX

Issue description

When exporting my project in GLES3 mode, Chrome will lockup for at least 10 seconds when starting the project every time.

This does not happen with the GLES2 export.

Steps to reproduce

  1. git clone git@github.com:tavurth/godot-simple-fps-camera.git
  2. Open the project
  3. Run the web version from godot

Minimal reproduction project

https://github.com/tavurth/godot-simple-fps-camera

Calinou commented 2 years ago

Duplicate of https://github.com/godotengine/godot/issues/21957. https://github.com/godotengine/godot/pull/53411 may improve the situation, but it will probably not help on the first start (only on subsequent starts). Can you try building the latest 3.x branch from source (which includes https://github.com/godotengine/godot/pull/53411) and see if the issue persists? You'll need to compile both an editor and HTML5 export template. Set the shader caching mode to Asynchronous + Cache in the Project Settings, then export the project to HTML5.

Firefox may fare better with regards to startup times, but GLES3 shader compilation will always take a longer time compared to GLES2 (since its shaders are more complex). On top of that, macOS is a worst-case scenario when it comes to WebGL support, as it has to go through Apple's own OpenGL → Metal translation.

tavurth commented 2 years ago

Hi @Calinou the issue linked to is also closed, I will try to compile the latest 3.x branch, but I feel we should leave at least one of these two issues open until it's resolved?

clayjohn commented 2 years ago

Yes, let's leave this open until we have confirmed that shader compilation is the issue and shader caching resolves it.

tavurth commented 2 years ago

I managed to build the OSX 3.x branch, but when trying to build the export templates for HTML5 I run into the following error:

▶ scons platform=javascript tools=no target=release_debug

scons: Reading SConscript files ...
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'SDKVersion' in SDK 'iphoneos'
Failed to find SDK version while running xcrun --sdk iphoneos --show-sdk-version.
Detected iOS SDK version older than 13
Invalid target platform "javascript".
The following platforms were detected:

    osx
    server

Please run SCons again and select a valid platform: platform=<string>

Interestingly the docs don't actually specify how to load a compiled export template.

I compiled the Mac export template by accident and I'm left with the file godot.osx.opt.debug.x86_64 but when selecting it as the debug export template, the following error is shown:

Screenshot 2022-01-10 at 21 15 47

Unfortunately I think the docs need some work in this area and I haven't been able to find that info elsewhere online.

Calinou commented 2 years ago

I managed to build the OSX 3.x branch, but when trying to build the export templates for HTML5 I run into the following error:

As described in the Compiling for the Web documentation, you need to install the Emscripten SDK and load it in your environment by running ./emsdk_env.sh activate.

Interestingly the docs don't actually specify how to load a compiled export template.

After compiling an export template, load the generated ZIP file from the bin/ folder in the HTML5 preset's custom release export template field (assuming you compile an export template with platform=javascript tools=no target=release).

Each platform uses its own file extension – the automatically generated ZIP files are only for HTML5 export templates.

tavurth commented 2 years ago

Thank you @Calinou that worked!

I can confirm this issue still persists with shader caching mode set to Asynchronous + Cache in the GLES 3 options.

Locks up the whole web browser and the tab can't be quit easily. If there are any other tests I can run I will try also now it's compiled properly.

tavurth commented 2 years ago

Pretty much all hardware still supports WebGL1 significantly better than WebGL2. We were spending too much development effort creating hacks to appease WebGL2 when WebGL1 just works better and is faster anyway.

From the other thread ^

Seems that this is unlikely to be fixed soon, perhaps we can re-open the other issue in place of this one as there is helpful testing which has been listed there?

Calinou commented 2 years ago

Seems that this is unlikely to be fixed soon, perhaps we can re-open the other issue in place of this one as there is helpful testing which has been listed there?

Both issues are unlikely to be fixed soon, so it doesn't really matter which issue is left open by now (or if both are closed).

tavurth commented 2 years ago

I see this a lot in public projects now, but I don't remember it being a problem before.

Since this effectively makes my entire browser unusable (Chrome 100.0.4896.20), I think it can be pretty bad for Godot PR.

I would suggest that until this issue is fixed, we limit Web exports to GLES2 to prevent people from pushing more bad PR material about the Godot engine online.

Alternately, if this issue has been introduced more recently perhaps we can bisect the issue and figure out where it went wrong?

Calinou commented 2 years ago

I wouldn't prevent exporting GLES3 projects to HTML5, as it does work for some specialized use cases (including the web editor), especially in Firefox. The documentation already recommends using GLES2 for projects that are planned to be exported to HTML5.

Alternately, if this issue has been introduced more recently perhaps we can bisect the issue and figure out where it went wrong?

This has always been an issue since Godot 3.0's release. It's just that web browsers are bad at compiling complex WebGL 2.0 shaders. Browsers are unlikely to improve on this aspect, given how complex WebGL 2.0 is outside their developers' focus. There's nothing we can do about it.

I can confirm this issue still persists with shader caching mode set to Asynchronous + Cache in the GLES 3 options.

I remembered that it's actually impossible to have working shader caching in HTML5, because the program binary OpenGL extension isn't available there. Parallel shader compilation was only recently added to Chromium-based browsers, and it hasn't been added to Firefox yet:

tavurth commented 2 years ago

The documentation already recommends using GLES2 for projects that are planned to be exported to HTML5.

Seems like most people don't read the docs so deeply, and it's a shame to see projects run foul of this. In the last month these two fairly high profile ones stood out for me:

https://github.com/jayaarrgh/BookOfShaders-Godot/issues/7

https://github.com/ceceppa/anima/issues/26

I wouldn't prevent exporting GLES3 projects to HTML5, as it does work for some specialized use cases

I notice that Godot has come a long way in implementing warning flags on the nodes when they are applied in the wrong areas. (_get_configuration_warning).

I think this issue might be a great way to push for more of the same, and rather have a large similar warning when people try to export GLES3 for HTML5. What do you think of this idea?

tavurth commented 8 months ago

Holy moly, Godot 4.x has just completely broken web exports?

I've been trying to export a game for WebGL but it just hangs on loading? I've noticed the same for other examples as well.

Chrome 119.0.6045.159

Screenshot 2023-11-28 at 22 21 01
Zireael07 commented 8 months ago

Yours is a separate issue - this one has been fixed for a year or so

tavurth commented 8 months ago

@Zireael07 I mean it still causes my Chrome to lockup, it's just more than 30 seconds now 😓

Actually have to kill the whole browser now whenever a Godot 4.x HTML5 game or tool launches.

This tool I've built has zero custom shader usage.

I guess you are right in that it is no longer GLES-3. Perhaps this issue was always mislabeled in that case?

Zireael07 commented 8 months ago

No, it's not mislabeled, as this issue was opened for a specific Godot version at that time. You're using 4.x, which is an entirely different beast from 3.4.2

akien-mga commented 8 months ago

@tavurth Your issue is #70691. It's a problem specific to Chrome on macOS.

tavurth commented 8 months ago

Ok thank you both.

I guess the similarity between both issues is that the shaders requested to be compiled are huge in size?

Is there some way in either godot version (3.x or 4.x) to disable shaders that one doesn't need?

tavurth commented 5 months ago

Yours is a separate issue - this one has been fixed for a year or so

~Also anyone still on 3.x can confirm this? Otherwise I guess we would be good to close @Calinou?~

Edit: Just tested this on 3.5.3 with fresh export templates. This issue is still very much present.

GLES2 is fine, GLES3 locks up the whole web browser. (Chrome 121.0.6167.85)