Windows: run WebGL contexts on the WebGL thread

[triniwiz]

Summary

WebGL on Windows ran on the JS thread, which is the UI thread, so every ANGLE call blocked it. Shader compiles and links (D3D HLSL compilation) froze the UI, the more so with several WebGL views on a page. On-screen contexts now run on the shared nsc-webgl thread that Android (#174) and iOS (#176) contexts use, reached through the same WebGLState::post / sync. getContext(..., { threaded: false }) opts out, and offscreen contexts stay on the JS thread, as on Android.

• Creation and attach: canvas_native_webgl_create_d3d_threaded makes the context on the WebGL thread. The panel's swapchain is made there and bound on the UI thread; a transparent canvas presents into its SurfaceImageSource through a XamlHandoff, as threaded 2D does. Resizes and swapchain transforms are queued.
• Present: queued. The thread never waits on the display, since a hidden panel would stall every context on it. A frame the swapchain isn't ready for is copied aside and shown from the thread's retries, unless a newer frame comes first.
• Context loss: a present that finds the context lost records it, so isContextLost() needs no round trip.
• ANGLE's immediate context is multithread-protected: presents copy with it outside ANGLE's lock while contexts on the UI thread call into ANGLE.
• napi bindings: the ones that reached the GL state directly (shader and program queries, getExtension, WebGL 2 uniform blocks and invalidation) go through sync, and their extensions follow the context's thread.
• Frame pacing: CanvasModule.__canvasesBehind is exposed from the napi addon, so requestAnimationFrame is held back while a threaded 2D or WebGL canvas is behind, as on Android and iOS.
• Canvas.threadedWebGL (default true on Windows) sets the default. Rebuilt x64 and arm64 canvasnative.node are in the branch.

Testing

• New crates/canvas-c/tests/threaded_webgl_d3d.rs (cargo test -p canvas-c --features 2d,webgl,gl,d3d --test threaded_webgl_d3d): threaded frames read back like unthreaded ones; presenting into a headless panel that never takes frames (held, then forced out), resizing, and dropping a context with a frame still held; four threaded contexts linking programs beside one on the calling thread. threaded_d3d still passes.
• Windows 11 (Intel Iris Xe), apps/demo, on master with OffscreenCanvas #175 and iOS: threaded WebGL on a CAEAGLLayer, deleteProgram fix #176: webgl 83/83, offscreen 37/37 (an OffscreenCanvas's detached WebGL host is threaded now too), 2d 180/180; the WebGL perf demo runs on screen through the thread.
• Not tested: several WebGL views on screen at once in the app (canvas-busy lays out nothing on Windows, threaded or not); the Rust test above covers several contexts on the thread.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 7708a329-4a97-4222-88f8-763f39b2c804

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}