Construct WebGPU status thread

Support for WebGPU in Construct is a major upgrade involving a great deal of work and some backwards compatibility risk. Therefore support for WebGPU is being rolled out gradually in steps. This forum thread will indicate the current status of support for WebGPU in Construct as it will be evolving over time.

Background

For more details about what WebGPU is and what this change means, see these blog posts:

1. A brief history of graphics on the web and WebGPU
2. From WebGL to WebGPU in Construct
3. Introducing Construct's new WebGPU renderer

Addon developers

If you are an effect developer you will need to port any existing effects to WGSL to support WebGPU. For more details about this see the Addon SDK documentation on WebGPU shaders.

Activating WebGPU

For WebGPU to be used in your project, it must be enabled for all four of:

1. The chosen preview/export option
2. The browser engine
3. The local device's software/hardware
4. The project settings

These are described in more detail below.

Export support

WebGPU is being enabled separately for individual export options as they become supported. The list below indicates which options WebGPU currently can be enabled on. In the long term we aim to support all platforms.

• Preview / Remote Preview: supported from r337+
• Web / Construct Arcade: supported from r345+
• Android: supported from r380+
• iOS: supported from r479+
• Windows WebView2: supported from r345+
• macOS WKWebView: supported from r479+
• Facebook Instant Games: not yet supported
• Playable Ads: not yet supported

Browser engine support

WebGPU must also be supported by the underlying browser engine. The list below indicates the current support for WebGPU in browsers. We expect that in the long term, WebGPU support will become as ubiquitous as WebGL.

• Chrome/Edge (and other Chromium-based browsers/platforms): currently supported in v113+ for Windows, macOS and ChromeOS; Android from v121+; and Linux on Intel GPUs from v144+ (see this issue for further updates on Linux support).
• Safari/iOS: supported in Safari/iOS v26+. Note however due to a Safari bug WebGPU rendering is glitchy from v26.0-26.3. It should however work correctly from v26.4+.
• Firefox: currently supported in v141+ on Windows and v147+ on macOS on Apple Silicon devices. Note however a Firefox bug means macOS support only works in v151+. Other platforms are planned but not yet supported.

Hardware support

Even with a supported export option on a supported browser/platform, you are not guaranteed to get WebGPU support. This is because it requires relatively modern hardware and software.

There is not currently any real public documentation on what kind of system requirements there are for WebGPU. However Web3DSurvey.com's WebGPU statistics show a sample of support for a range of platforms indicating how prevalent support is for particular platforms. The main thing to note is if you fulfil all these requirements and still don't get WebGPU support, it may be because your system is not supported; in that case try a newer and more up-to-date system if possible.

In the Chrome or Edge browsers you can also visit about:gpu to see diagnostic information about the GPU and WebGL and WebGPU support.

Project settings

As of r450+, Construct enables WebGPU in your project settings by default. (The default setting for Use WebGPU is Auto, which currently means enabled.)

If you want to disable WebGPU for a project for any reason, go to the Advanced section of project properties, and set Use WebGPU to No.

Note that if the project uses any third-party effects, these must have been updated to support WebGPU. Contact the addon developer for support if you need an effect ported to WebGPU.

Verifying WebGPU is in use

The easiest way to check that WebGPU is active in your project, meeting all the above support requirements, is to add a Text object to your project and display the PlatformInfo.Renderer expression in it. This will return webgpu when the WebGPU renderer is in use, otherwise it will say webgl1 or webgl2.

Other ways to check are also:

• Open Construct's debugger; the second last item in the debugger subtitle includes the same renderer string as the PlatformInfo.Renderer expression, which will also be webgpu if WebGPU is in use.
• Open the browser console (typically by pressing F12) and look for the console log message indicating Construct's renderer. This should include a line that reads something like "[C3 runtime] Hosted in worker, rendering with WebGPU" if WebGPU is in use; otherwise it will refer to WebGL.

Editor support

As of r450+, Construct now also enables WebGPU by default for the Construct editor, where it is used to render the Layout View. This will also use the WGSL variants of effects in the editor. If for any reason you want to go back to using WebGL for the editor, you can do this in Settings by changing Enable WebGPU in editor to No. (Much like the Enable WebGPU project property, this defaults to Auto, which currently means enabled.)

You can verify WebGPU is in use in the editor by choosing Menu > About > Platform information. If the editor is using WebGPU, then the Platform Information dialog will list WebGPU information instead of WebGL information.

Issues

If you run in to any problems when WebGPU is active, please file an issue for them the usual way, including following all the bug report guidelines, and stating that the issue is specific to WebGPU.

Known issues

Here is a list of known issues with WebGPU that are currently being tracked.

• As noted above, Safari 26.0-26.3 support WebGPU, but a Safari bug can make the display look glitchy. It should work correctly with Safari 26+.
• As noted above, Firefox 147-150 supports WebGPU on macOS, but a Firefox bug prevents using the WebGPU renderer (Construct automatically falls back to using the WebGL renderer). It should work correctly with Firefox 151+.
• Texture upload performance can be worse than WebGL, causing performance issues particularly with rapidly changing or scaling Text objects. See https://issues.chromium.org/issues/40273077. Possible workarounds are to set the Text object in to fixed resolution mode for faster scaling, or just disable WebGPU and continue using WebGL.
• See also open Construct issues tagged 'webgpu'

Conclusion

WebGPU is a major technology upgrade for both the web and for Construct. We expect to see some significant benefits to supporting WebGPU, including substantially improved performance in some cases. However with major new technologies comes some risk, and so we are taking precautions and rolling out support gradually. Be sure to check back here in future as the support status will be changing over time and this thread will be updated accordingly.

Yes, Construct will always fall back to WebGL if WebGPU is not supported for any reason. If enabled it tries WebGPU first, then falls back to WebGL 2, then falls back to WebGL 1.

Now that r380 ships with WebGPU enabled for Android I‘ve done some tests myself and thought I’d share them here :) The results unfortunately weren’t too promising…

The past few system webview updates have brought significant performance improvements for my game for webGL 2, while webGPU causes severe stuttering issues on my 7 Pro test device, as you can tell from these videos. Furthermore, it sometimes causes longer hiccups and especially struggles with displays that support a dynamic refresh rate (disabling this feature improves performance significantly, but it’s still worse than webGL). Performance on my (relatively slow) Galaxy S8 with webGL is a lot better in comparison. iOS webGL performance, while not amazing, is much better too.

I‘m hoping for future webGPU or Construct updates to improve this in the future, but for now I think I‘ll have to disable webGPU for my exports.

I‘ll work on a test project once I have time. But fyi, the "boat scene" in my game doesn’t use any effects and still stutters severely. It‘s just sprites moving, a few animations playing and a few objects running opacity tweens. I think pretty much any construct game using high-res instead of pixel art graphics will reproduce this, on the pixel devices at least.

So I've spent hours trying to replicate my issue of near constant stuttering and it was extremely difficult. For me, objects are at least rendering fine, both in the webview beta as well as the stable version.

Edit: I thought that the Compositing Mode made a difference, in reality, it just didn't use webGPU this time, after reinstalling the web view it did it again. Composition mode also makes no difference for webGL on this device at least.

I've created a test project that stutters sometimes, like once a minute, on my test device but it's not even close to my main project. I'm not sure what the difference is exactly, because I've removed most code and almost all behaviors from the main project as a test and then the performance was fine. However, cpu usage is extremely low across the board in the project so I don't quite get how that could make a big difference. Furthermore, gpu usage is rather high but fine too. What causes the lag spikes according to the graphing tool on android is Misc / Vsync Timeout which is not very helpful but yeah. Also with the refreshrate down to 60 the stutters are far less noticable. The sample project also sits in the drive folder.