Bug 294602 – [WebGPU] Very poor texture upload performance when passing canvas

• Status: NEW
• Component: WebGPU

[Ashley Gullen]

Steps to reproduce:

Visit repro URL and observe framerate: https://downloads.scirra.com/labs/textscaling/webgpu4/index.html

NOTE: this issue requires WebGPU support to reproduce which is currently only enabled in pre-release channels. Check that WebGPU is logged to the browser console to verify. This reproduces for me in Safari TP 221.

The repro URL renders text at lots of different scales by drawing text to canvas2d and then uploading that as a texture. This is a way to get high-quality text rendering in WebGPU as it does not have any direct way to render text. It's used by our web-based game engine Construct (www.construct.net).

Actual results:

The performance of doing this is extremely poor. The test runs at around 3 FPS on an M1 MacBook Pro.

Expected results:

On a high-end system this should be able to achieve a smooth 60 FPS. Indeed Chrome rendering with WebGL can achieve that.

Safari's WebGL renderer is also slow doing the same thing (see WebGL test: https://downloads.scirra.com/labs/textscaling/webgl/index.html). It would be nice if it was fixed for WebGL too, but for the future the main thing we care about is that it's fast in WebGPU.

[Mike Wyrzykowski]

Issue reproduces, however I observe ~5 fps on my Mac Studio using Chrome 139.0.7244.0 (Official Build) canary (arm64) so does not appear unique to WebKit

[Mike Wyrzykowski]

Upload path between 2D canvas and WebGPU could certainly be improved.

[Mike Wyrzykowski]

Right now we make a full read back of the IOSurface contents to the Web content process, copy (CPU side) to an array, send that back to the GPU process, and then upload that back to the GPU.

In theory we should be able to skip the web content and CPU side part and use the 2D canvas directly in a MTLTexture without leaving the GPU process as these are all backed by IOSurfaces.

[Radar WebKit Bug Importer]

<rdar://problem/153642354>

[Ashley Gullen]

FWIW I filed a Chrome issue about this here as well: https://issues.chromium.org/issues/40273077
It looks like they have a fix in progress (although it is taking a while).

[Gregg Tavares]

Created attachment 475601 [details]
webgl repo

a standalone webgl repo

[Gregg Tavares]

Created attachment 475602 [details]
webgpu repo

a webgpu repo

[Mike Wyrzykowski]

Thank you Gregg for the repros :)

[Mike Wyrzykowski]

This should be resolved by https://bugs.webkit.org/show_bug.cgi?id=263692 but I hesitate to dupe it so we ensure it is fixed when https://bugs.webkit.org/show_bug.cgi?id=263692 is completed

[Ashley Gullen]

FWIW I have an updated repro as we have made some changes to our WebGPU rendering code to try to handle this more efficiently: https://downloads.scirra.com/labs/textscaling/webgpu-batched/index.html

It no longer generates mipmaps, and it also batches all texture uploads together to avoid creating render passes in between every texture upload. This still only gets about 5 FPS on macOS 26 for me though.

[Mike Wyrzykowski]

Created attachment 477211 [details]
PoC

I have an initial implementation for this.

60fps now when Gregg's repro (thank you Gregg)

Performance of the original site matches Chrome Canary on my Mac

[Mike Wyrzykowski]

Pull request: https://github.com/WebKit/WebKit/pull/53089

[Mike Wyrzykowski]

*** Bug 263692 has been marked as a duplicate of this bug. ***

[Ashley Gullen]

Here's an updated repro where we've further tried to optimize things on our side: https://downloads.scirra.com/labs/textscaling/webgpu-two-phase/index.html

This now updates all canvases, before proceeding to upload all canvases to WebGPU textures with consecutive calls to copyExternalImageToTexture(). However it does not appear to have improved performance much in Safari 26.1.

[Mike Wyrzykowski]

My pull request has some potential for race conditions as I supported zero copies in image sources as well. We are also working to make copies faster between all sources and WebGL + 2d canvas.

I can see if I can limit the PR to canvases so the race condition is only required to be addressed for that path