migration: real WASM viewer fails OffscreenCanvas WebGL2 compatibility in Linux smoke

[zackees]

Real acceptance run after kernel webview adoption compiled an isolated Blink sketch successfully using catalog Emscripten 4.0.21 and clean /home/niteris/dev/fastled source (FastLED 6.0.0). Executed the newly built CLI with --test --test-screenshot --test-log --test-exit-on-error --test-timeout-secs 60 --no-https under isolated Xvfb/dbus, GDK_BACKEND=x11, LIBGL_ALWAYS_SOFTWARE=1 and WEBKIT_DISABLE_COMPOSITING_MODE=1.

Viewer logs: OffscreenCanvas, SharedArrayBuffer and transferableObjects all true; WebGL2 OffscreenCanvas test says SUCCESS, but final capabilities webgl2=false. window.onerror reports Browser compatibility check failed: WebGL2 not supported with OffscreenCanvas. CLI exits125 after no rendered canvas before readiness timeout. The generated index.js gate rejects workerCapabilities.webgl2 != true. No screenshot produced. Source checkout stayed clean. This is not a successful render proof and must not be bypassed by weakening readiness or browser checks.

Investigate actual worker context capability and Linux backend/environment parity, then rerun real WASM render/capture and supported browser checks including Safari. Earlier minimal-canvas native fixture passes but does not exercise the real WASM worker. Refs #242. Local reproduction logs: /tmp/fastled-arguments-wasm.nATPLZ/viewer.log.

[zackees]

Follow-up: removing WEBKIT_DISABLE_COMPOSITING_MODE did not change the failure (exit125, webgl2=false). The SUCCESS log is misleading: worker_manager detectCapabilities logs it unconditionally after getContext returns, including when it returns null. This probe runs in the main document, before worker startup; it is not yet evidence of a worker-only failure. The pinned Wry Linux backend already calls set_enable_webgl(true). Next isolate Mesa/EGL setup without weakening browser capability checks.

[zackees]

Explicit software Mesa diagnostic also failed identically: compositing override unset, Mesa EGL vendor JSON selected, LIBGL_DRIVERS_PATH set to the system driver directory, and llvmpipe selected. The real WASM compile remains green; OffscreenCanvas.getContext(webgl2) returns null before worker startup. This narrows the observed failure but does not prove a kernel regression. No code or capability gates were changed.

[zackees]

Comparison run on this host to separate environment from migration effects.

Same inputs for both: the Blink sketch from the earlier repro, FastLED source 9aa7254bba (clean), Xvfb :97 with GDK_BACKEND=x11 LIBGL_ALWAYS_SOFTWARE=1 under dbus-run-session, and --no-https --test --test-exit-on-error --test-timeout-secs 60 --test-screenshot --test-log.

Binary	Result
origin/main 22ea046 (Tauri viewer, pre-migration)	exit 125, no screenshot, Final capabilities: {... "webgl2": false}, Browser compatibility check failed: WebGL2 not supported with OffscreenCanvas
feat/kernal-api-migration eb5a51d (kernal-api v0.1.3 viewer)	identical: exit 125, no screenshot, same capabilities and error

Conclusion: the pre-migration Tauri viewer fails the same way, so this is not a kernal-api migration regression. OffscreenCanvas WebGL2 isn't available under this host's software GL stack. No readiness or browser checks were weakened. Real-render acceptance still needs a GPU-backed host, and Safari still needs a real macOS smoke test.

Refs #229, #242.

[zackees]

Follow-up: rechecked after NixOS commit 9f90cf4 ("Run locally built Tauri/WebKitGTK apps on X11 and Wayland"; active as system generation 118). The result doesn't change.

Branch binary (kernal-api v0.1.3), same Blink sketch, FastLED source and --test flags, launched through the new tauri-run wrapper:

Display	Result
Real Wayland session (wayland-0), no forced software GL	exit 125, no screenshot, webgl2: false
Real X11 (DISPLAY=:0, GDK_BACKEND=x11), no forced software GL	exit 125, no screenshot, webgl2: false
Xvfb :97 + LIBGL_ALWAYS_SOFTWARE=1 (original repro)	exit 125, no screenshot, webgl2: false

Why: the commit only adds library paths, the glib-networking HTTPS module and GSettings schemas for locally built GTK/WebKit binaries. It doesn't change GL/EGL/driver setup. Outside WebKit, eglinfo shows this session has only software rendering (Mesa llvmpipe on Wayland), GBM eglInitialize failed, and GLX on :0 returns BadValue. nvidia-smi reports Driver/library version mismatch (kernel module 595.71.05, userspace 595.99.02). The NixOS notes say a reboot clears it.

Next step: reboot, confirm nvidia-smi works and eglinfo -B shows an NVIDIA renderer, then rerun this check.

Side note: tauri-run doesn't add liblzma/libbz2, which fastled links, so the binary also needs those library paths to start through it.

Refs #229, #242.

[zackees]

Root cause found. After a reboot, the NVIDIA mismatch is gone and hardware GL works: EGL on GBM/Wayland/X11/surfaceless/device and GLX on :0 all report NVIDIA GeForce RTX 3060, with direct rendering. The real viewer still fails, both the migration branch (0ff5112, kernal-api v0.1.3) and pre-migration origin/main (Tauri): webgl2: false, exit 125, no screenshot, on Wayland and X11.

The blocker is WebKitGTK's AllowWebGLInWorkers runtime feature, which is off by default in WebKitGTK 2.52.5. MiniBrowser --features=help lists OffscreenCanvas and OffscreenCanvasInWorkers as enabled but AllowWebGLInWorkers as disabled. Despite the name, the flag gates WebGL on every OffscreenCanvas, including ones created in the document. Probe page run in the bundled MiniBrowser on the GPU-backed Wayland session:

Context	Default features	--features=+AllowWebGLInWorkers
<canvas> getContext('webgl2')	ok	ok
document OffscreenCanvas webgl2	null	ok
document OffscreenCanvas webgl	null	ok
worker OffscreenCanvas webgl2	null	ok

(The renderer string reads "Apple GPU" because WebKit masks it for privacy.)

The frontend gate in fastled_worker_manager.ts calls new OffscreenCanvas(1, 1).getContext('webgl2'), gets null and rejects the browser. Its "WebGL2 OffscreenCanvas test: SUCCESS" log is printed unconditionally, which is why the log looked contradictory. wry 0.57 calls set_enable_webgl(true), and kernal-api's Linux setup only sets renderer environment variables and media/WebAudio settings. Neither enables this feature, so neither Tauri nor the kernel viewer can pass today.

Fix direction: enable AllowWebGLInWorkers on the WebKit settings before the first navigation, through webkit_settings_get_all_features / webkit_settings_set_feature_enabled (WebKitGTK 2.42+). Chrome, Firefox and Safari 17+ all enable WebGL on OffscreenCanvas by default, so this matches the web platform rather than weakening a check. The frontend's unconditional SUCCESS log should also be fixed.

Refs #229, #242.

[zackees]

Correction to my earlier comments. I said the original Xvfb failure came from this host's software GL stack. That was wrong. The same MiniBrowser probe under Xvfb with LIBGL_ALWAYS_SOFTWARE=1 (Mesa llvmpipe) shows the software renderer handles OffscreenCanvas WebGL once the WebKit feature is enabled:

Context (Xvfb + software GL)	Default features	+AllowWebGLInWorkers
<canvas> webgl2	ok	ok
document OffscreenCanvas webgl2	null	ok
document OffscreenCanvas webgl	null	ok
worker OffscreenCanvas webgl2	null	ok

So every failure recorded on this issue, headless software, real Wayland and real X11, before and after the reboot, has one cause: WebKitGTK's AllowWebGLInWorkers feature is disabled by default. The NVIDIA driver/library mismatch was real, but it wasn't what blocked the viewer.

This also means the Xvfb-based tauri-webview-smoke CI job in kernal-api can prove the fix, failing before and passing after.

The fix goes in kernal-api (enable the feature on the WebKit settings before first navigation), released and cascaded to fastled-wasm. No local workaround will be added here.

Refs #229, #242.

[zackees]

Update: fix in kernal-api, one remaining upstream blocker.

Root cause of the WebGL2 gate failure: WebKitGTK's AllowWebGLInWorkers runtime feature is disabled by default and gates WebGL on every OffscreenCanvas, including document-created ones. It fails the same way with hardware GL (NVIDIA, after the reboot) and with software GL, and in the stock MiniBrowser. The NVIDIA driver mismatch I reported earlier was real, but it was not the cause.

Fix (in kernal-api, no local workaround):

• fix(webview): enable WebGL on OffscreenCanvas in WebKitGTK views zackees/kernal-api#268 → release/0.1.3, for v0.1.4
• fix(webview): enable WebGL on OffscreenCanvas in WebKitGTK views zackees/kernal-api#269 → main

The Linux adapter enables the feature on each view before its first navigation, through the WebKitGTK 2.42+ feature API resolved at run time. A new offscreen-webgl CI smoke scenario fails with the facade call disabled (webgl2=0) and passes with it; the existing scenarios, unit tests, Clippy and fmt pass.

Checked with FastLED: Blink built against the patched kernal-api on the NVIDIA Wayland GPU session reports webgl2: true. The compatibility gate passes and the worker creates a WebGL2 context. The viewer still exits 125 without reaching readiness.

Remaining blocker (upstream): on WebKitGTK 2.52.5 with NVIDIA 595.99.02 under Wayland, a document WebGL2 context followed by worker rendering on a transferred canvas breaks the UI process (Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display). The web process then segfaults in libnvidia-eglcore from GLContext::~GLContext → PlatformDisplay::clearGLContexts → WebProcess::stopRunLoop. Worker-only rendering works. This reproduces in the stock MiniBrowser with a minimal page, so it is an engine/driver bug. A WebKit Bugzilla report with the repro is drafted and needs to be filed from a Bugzilla account.

Separately, with software GL, only the first thread to create a WebGL context succeeds; a later context on the other thread returns null.

Next: merge #268 after CI, release kernal-api v0.1.4, then bump fastled-wasm (#242) to it.

Refs #229, #242.

[zackees]

fastled-wasm now consumes the fix. kernal-api v0.1.4 is published (release run 34917338991, all jobs green). It contains zackees/kernal-api#268, which enables WebKitGTK's AllowWebGLInWorkers feature in the Linux webview adapter.

#242 now pins kernal-api to the v0.1.4 tag (commit 966c735). With that locked, the Rust workspace tests, the Python unit tests (including the boundary test's tag check) and bash lint pass locally. The same commit fixes the frontend's WebGL2 probe log, which no longer reports SUCCESS when getContext returns null, and corrects the migration audit's account of this issue.

Real rendering on the NVIDIA Wayland session is still blocked by the upstream WebKitGTK 2.52.5 + NVIDIA 595.99.02 crash described above. No local workaround has been added. The same fix for kernal-api main is open as zackees/kernal-api#269; its failing checks are pre-existing on main.

[zackees]

Correction: not an upstream WebKitGTK/driver blocker

My earlier comments here called the viewer failure on NVIDIA Wayland an upstream WebKitGTK/NVIDIA crash. That was wrong. Here is what re-testing on the same host shows.

What actually failed

• The MiniBrowser "reproduction": it ran without __NV_DISABLE_EXPLICIT_SYNC=1, the NVIDIA Wayland fix the viewer already applies (fix(viewer): apply NVIDIA and WebKitGTK workarounds before creating the webview #226). It does not reproduce the viewer's behavior.
• The earlier Blink captures: Blink sets no screen map in setup(), so the viewer never gets a layout. That is a separate bug, now tracked in Viewer shows an empty canvas for sketches that set no screen map in setup() (e.g. Blink) #250.
• The real regression: kernal-api v0.1.4 forces WebKitGTK's AllowWebGLInWorkers. On NVIDIA Wayland (DMA-BUF) the worker renderer then crashes the web process: a Skia GrResourceCache SIGILL, after which the canvas freezes. Result: 5 of 8 runs froze.

What works: main-thread rendering, FastLED #4405

This is the path the pre-kernal-api viewer used on Sep 12. With worker WebGL left at WebKitGTK's default, the worker posts frames to the page, which draws them.

• Wayland: 7 of 7 runs animated.
• X11: 3 of 3 runs animated.
• The Skia crash never occurred.

A separate NVIDIA libnvidia-eglcore SEGV shows up in both configurations, including the pre-kernal-api one. It does not stop rendering.

Fix

• kernal-api: revert the forced feature (fix(webview): stop forcing WebGL on OffscreenCanvas in WebKitGTK views zackees/kernal-api#272), then cut a new release. The main-branch port, fix(webview): enable WebGL on OffscreenCanvas in WebKitGTK views zackees/kernal-api#269, is closed unmerged.
• fastled-wasm frontend: port FastLED #4405, the main-thread fallback.
• --test harness: read the page canvas in that mode.