SBS video tile disappears from the page after a GPU-process restart (samples/windows, inline3d 1.6.1)

[dfattal]

After a GPU-process restart the SBS video tile disappears from the page (samples/windows, SDK 1.6.1)

Observed on the win box, 2026-09-10, during browser-pvt#100 Test C (deliberate gpu-process kill under a live weave; Chrome reinitialised the GPU process in 829 ms).

• Page: local copy of samples/windows with the importmap pinned to @displayxr/inline3d@1.6.1. Video via wall.addVideo(document.getElementById('movie'), makeSbsVideo()).
• Before the kill: video tile present and woven (David's eyeball: "everything else woven 3D").
• After the kill: "the video element is not here at all" — gone from the layout. The browser's own log agrees: the tile is no-join@0,0 0x0 / offscreen tile … registered but not composited; no quad expected in every post-restart frame — a zero-size element, not an off-screen one.
• three.js logged Context Lost → Context Restored and its crate came back. The SDK's video path paints through a 2D canvas (getContext('2d')) — no WebGL involved — so this is not a context-loss gap. The likely chain: the <video> decoder lived in the killed GPU process; when it died the media element lost its metadata / went to an error or empty state; whatever sizes the movie canvas from the video's dimensions then collapsed it to 0×0. The sample's makeSbsVideo() has a play().catch(kick) for autoplay policy but no error/emptied/stalled handling, and I could not find a videoWidth resize path in the bundle to point at.

Not a browser (viz) issue: the tile's quad was never suppressed, so there is no hole; it is a page/SDK recovery gap after GPU restart. Filed here because the SDK owns the canvas sizing. Repro: any page with an SBS video tile → Shift+Esc → end the GPU process.

Browser log preserved on the win box: C:\dxr-99-hwcheck\capture-testC\browser-A2b-postC.log.

[dfattal]

Code facts from the SDK side (1.6.1): _sizeBuffer sizes the backing store from the canvas's CSS box (_eyeSize, js/inline3d.js:2181), not from videoWidth, and samples/windows gives the movie canvas a fixed .stage.wide box — so a 0×0 TRACKED rect after the GPU restart is not the page collapsing the box; it is cc reporting the canvas layer as not composited (registered but not composited), i.e. the accelerated 2D canvas lost its GPU backing and its compositing layer did not come back. Independently, _paint (js/inline3d.js:2302) reads src.videoWidth || src.naturalWidth || src.width; a <video> whose decoder died with the GPU process reports videoWidth 0, so every per-frame repaint draws nothing — which also starves the aggregated-frame presence that keeps the layer alive (the every-frame-repaint rule in _frame). Two fixes, both SDK-side: (1) on a video with videoWidth==0 / readyState<2 after it once had frames, re-commit the last frame (the 1.6.1 _recommitLastFrame already exists for buffering — extend its trigger) and listen for error/emptied to call video.load() + play() again; (2) treat a window whose tracked layer vanished (visible box non-zero but no composited layer for N frames) as a repaint trigger. Repro: any inline-3D page with addVideo, Shift+Esc → end GPU process.