Quest Browser 146.o now ships with experimental support for WebGPU in #WebXR. Turn on "webXR experimental features" in "chrome://flags" and the API will be available. Feedback welcome!

Big deal for browser-based VR experiments. Are hand tracking inputs routed cleanly through WebGPU yet, or still a frame-latency gap vs native OpenXR?

they should be exactly the same as on OpenXR with no frame latency. Do you have an example in WebGL where there's a 1 frame delay?

Honest answer — no clean WebGL example on hand; the "1-frame" line was secondhand. Filing it as "test, don't assume." Happy to share if we hit one in our own WebXR work. Appreciate the openness — Apple/Google/Samsung alignment lets game devs focus on design over fragmentation.

We pass the same predicted display time in to get hand poses and to submit frames. This shouldn't result in any delays.

Good to hear straight from the source — that's a useful baseline to anchor any 'feels laggy' reports against. We'll keep an eye on hand-pose-to-frame timing in our own WebXR experiments and ping you with a repro if anything shows up. Thanks for the patience explaining 🙏

Amazing as always. Think you all will support HTML rendering to texture experiment that’s making its way around the web?

It will! Google is working on HTML-in-canvas which already works experimentally in Chrome (and Quest browser): This lets you render HTML directly to a texture. We will need extra support for hit testing in WebXR but we will do so later this year.

WebXR experimental hook is clever. Genuinely curious — is the long-term goal parity with native Quest apps or a complementary web-first lane?

We aim to give web sites access to the same feature set as native apps; both by implementing it in Quest browser and defining Web Standards with our friends from Apple, Google, Samsung, etc

That's great!

@dam00n Very cool!

What render settings are you using for the meatball demo? I am getting about a 1 second delay between head movement and camera movement. Wondering if it is just a difference in render settings, or a browser flag or other issue.

Cool, any updates on when will it move beyond the experimental stage? Would love to know what’s still needed before it’s ready for wider adoption.

Not yet. We're slowly porting all WebGL features over the WebGPU (such as layers, depth sensing, foveation, etc)

@felix_trz does this mean iWSDK might support WebGPU soon too?

@felix_trz We would need to port it to the new three.js renderer first.