Decouple WebXR from the render loop (fixes WebGPURenderer XR)

[bigmistqke]

Summary

solid-three internally drove the WebXR frame loop: on the renderer's sessionstart event it toggled renderer.setAnimationLoop(...) and set xr.enabled. That breaks WebGPURenderer — three's WebGPU XRManager snapshots the renderer's animation loop at setSession time (before sessionstart fires), so toggling on sessionstart is too late and overwrites the manager's own frame driver. Result on a Quest with WebGPURenderer: gl.getContextAttributes is not a function (when on the WebGPU backend), and on forceWebGL a hung headset with endless "Not all layers submitted" warnings.

This PR hands XR loop ownership to the consumer and reduces core to one responsibility: keep its own window loop out of the way while a session is presenting. Core now depends only on the stable, cross-renderer contract — gl.xr.isPresenting (read) and the consumer installing setAnimationLoop(render) before setSession — with no WebGL-vs-WebGPU branching. This also fixes a latent frameloop="always" + XR double-render.

What changed

• Deleted the internal XR driver (handleXRFrame, handleSessionChange, the xr connect/disconnect object, warnNonXR, the auto-connect effect, and the canDriveXR util).
• Window-initiated renders yield while presenting: a single isPresenting() predicate guards loop, requestRender, and the resize render in canvas.tsx. render itself is intentionally not guarded (the XR session calls it).
• One sessionend listener revives the window loop after exit (self-stopping guard handles the stop, so no sessionstart listener is needed). The post-XR repaint fires only in frameloop="demand", not "never".
• Context.render type corrected to (timestamp: number, frame?: XRFrame) => void so the XRFrame flows to useFrame.

Consumer migration (XR is now wired by you)

const { gl, render } = useThree()
// enter XR — install the loop BEFORE setSession:
gl.setAnimationLoop(render)
gl.xr.enabled = true
await gl.xr.setSession(session)   // e.g. three's AR/VR button
// exit:
gl.setAnimationLoop(null); gl.xr.enabled = false

Same code for WebGLRenderer and WebGPURenderer. For XR with WebGPURenderer on three ≤ r184, construct it with { forceWebGL: true } (WebGPU-backend XR is unreleased upstream).

Breaking

• Removed Context.xr ({ connect, disconnect }) — wire gl.xr directly.
• Context.render signature changed (delta → timestamp, added frame).

Test plan

• pnpm test — 151 passed, 2 todo (incl. new tests: window loop yields while presenting + resumes on sessionend; core leaves gl.xr.enabled alone; XRFrame forwarded to useFrame; listener detaches on renderer swap; renderer whose xr lacks addEventListener doesn't crash)
• pnpm lint:types — clean
• pnpm lint:code — clean
• On-device: verify WebGPURenderer({ forceWebGL: true }) + WebXR presents on Quest 3 (the original report)

Design + plan: docs/superpowers/specs/2026-05-29-xr-frameloop-decoupling-design.md.

🤖 Generated with Claude Code

[pkg-pr-new]

• solid-three-demo

  npm i https://pkg.pr.new/solid-three@58
  

commit: 64f5500

[bigmistqke]

createXR — the consumer-facing half of this change

Now that core no longer drives the XR loop, createXR is how you actually enter a session. It lives outside <Canvas> (next to your DOM "Enter XR" button) and wires to the renderer via <Canvas ref={xr.connect}>. Same code for WebGLRenderer and WebGPURenderer.

const xr = createXR()

<button onClick={() => xr.enter("immersive-vr")}>Enter VR</button>
<Show when={xr.isPresenting()}>
  <button onClick={() => xr.exit()}>Exit VR</button>
</Show>

<Canvas ref={xr.connect}>…</Canvas>

It absorbs the three ordering edges that this decoupling exposes, so consumers don't have to: setAnimationLoop(render) before setSession (WebGPU snapshots the loop there), setAnimationLoop(null) on sessionend (avoids the double-render), and requestSession first with nothing awaited before it (keeps user activation). Returns connect / enter / exit / isPresenting / session / isSupported. For controller/hand poses, read the XRFrame from useFrame's third arg — no need for createXR inside the scene.

WebGPURenderer note: the native WebGPU backend can't present WebXR yet — that integration is landing in r185 (tracked in mrdoob/three.js#32858). Until then, construct the renderer with { forceWebGL: true } to present over the WebGL2 fallback. createXR itself is backend-agnostic.

[bigmistqke]

continue work at #62 from a clean next branch