Support WebXR

Question

Support WebXR

jsantell opened this issue 6 years ago · comments

The webvr-polyfill should use native WebVR if it exists, fallback to a CardboardVRDisplay using sensors/devicemotion otherwise, and with this issue, should also map to a native WebXR implementation if it exists, and no native WebVR implementation found. This is necessary in the future as Chrome adpots WebXR, and deprecates the WebVR API.

Current plan is to ship this in webvr-polyfill by end of May.

Christopher Van · Answer 1 · Thu Apr 26 2018 06:09:36 GMT+0800 (China Standard Time)

thanks for the update. is there a timeline for the WebVR Origin Trials to complete? also, will WebXR undergo its own Origin Trial, or no?

Jordan Santell · Answer 2 · Fri Apr 27 2018 02:18:53 GMT+0800 (China Standard Time)

Intent to continue experimenting for WebVR (may be extended until September since WebXR delayed until m67
Intent to experiment for WebXR (dates a bit off)

Jordan Santell · Answer 3 · Fri Jul 13 2018 06:03:52 GMT+0800 (China Standard Time)

At this time, we're not going to support patching WebVR content code to be wired to WebXR for a few reasons:

Magic Window runs into the dual-canvas issue (developer has to be aware of the bound events on the canvas, which is no longer the presentation canvas). Hacks involving sharing contexts and the like are too fragile. Technically could be implemented with devicemotion events before entering exclusive. This is looking very fragile, and extremely unappealing to maintain.
Could generate XRSessions that are invisible just to get the pose for use in other magic windows, but discouraged by the spec, and while technically this could work, @toji considers this unreliable in the future. MS and Oculus browsers serve identity poses in magic window as a solution.
Many of the VRDisplayCapabilities can be grabbed from a RAF in XR, but that'd have to be spun up to be available when navigator.getVRDisplays resolves. Things like hasPosition, and the render size.
Sites that would want to map their WebVR content code to WebXR browsers would need to keep the in-flux polyfill up-to-date (WebXR is still rapidly evolving) and keep the origin trial tokens up to date, which sounds like more work than just upgrading to WebXR in the first place (using the webxr-polyfill to support non-WebXR browsers)
Worst case scenario, when having WebVR content being unsupported on a WebXR browser with no WebVR support (none exist currently), then we still have the cardboard fallback via webvr-polyfill.