TPAC: Evaluate if any aspects of the API should be deprecated.

[toji]

TPAC: Evaluate if any aspects of the API should be deprecated.

[tangobravo]

If inline sessions supported 6-DoF tracking or AR then I suspect they would have seen much wider usage.

One of the biggest downsides of WebXR for handheld platforms is the entanglement of presentation of the content (forced fullscreen, outside of DOM) with access to these underlying tracking features.

I've written at length about the problems this causes at immersive-web/webxr-ar-module#77 and proposed an inline-ar session as one potential solution at immersive-web/webxr-ar-module#79.

I don't have particularly strong feelings on the utility of the current inline session type either way. In general my preferred solution for AR use cases within the DOM is to completely separate presentation and underlying features, as discussed in immersive-web/webxr-ar-module#78.

[Manishearth]

Yeah I think this is probably worth discussing. They are clearly not doing their job right now and we should either make them better or remove them.

[Manishearth]

Discussed this a little bit with Ada and Rik.

In general it seems like mono inline VR is not used much, because it exists primarily as a convenience API to allow people to use WebXR for non-XR content using the same APIs; and that's only useful if people aren't already used to doing it a different way, which is what basically all the frameworks do.

However, there are two use cases of inline sessions that are not covered here:

• inline AR, "magic window" stuff, where you show a passthrough camera feed aligned to the real world
• stereo inline VR in a browser, showing 3D content that depends on pose that sits on the page, diorama style

The latter is already technically possible in the API: you can request viewer/local permissions when creating the inline session. Nobody implements this but I think it would be nice. It's a good reason to keep the API around if we can get someone to implement it, and perhaps we should write an example that uses this.

Magic window stuff would probably need inline-ar (and request viewer/local permissions, as before). That wouldn't be affected by deprecating this but it makes a nice symmetric set of features if we keep it around. We probably should explore that a bit.

[tangobravo]

In general it seems like mono inline VR is not used much, because it exists primarily as a convenience API to allow people to use WebXR for non-XR content using the same APIs; and that's only useful if people aren't already used to doing it a different way, which is what basically all the frameworks do.

Yup, sounds right to me. Looked at the other way round, it also doesn't really add any features that you can't implement with standard WebGL and doesn't have the same level of browser support so there's no compelling reason for frameworks to adopt it.

Wasn't one use case for the mono inline VR to do spectator mode on a secondary display for a PC with a connected headset? Though I suppose if you've got an immersive session already running in the same page you probably don't need anything other than a standard WebGL canvas as you can get all the required state from the immersive session callbacks.

However, there are two use cases of inline sessions that are not covered here:

• inline AR, "magic window" stuff, where you show a passthrough camera feed aligned to the real world
• stereo inline VR in a browser, showing 3D content that depends on pose that sits on the page, diorama style

The latter is already technically possible in the API: you can request viewer/local permissions when creating the inline session. Nobody implements this but I think it would be nice. It's a good reason to keep the API around if we can get someone to implement it, and perhaps we should write an example that uses this.

Sounds like a generalisation of the visionOS <model> element support to arbitrary content which sounds niche but potentially worth exploring.

Magic window stuff would probably need inline-ar (and request viewer/local permissions, as before). That wouldn't be affected by deprecating this but it makes a nice symmetric set of features if we keep it around. We probably should explore that a bit.

I'd be happy to remotely join a TPAC discussion [*] on the handheld AR use case again, but feel that deserves a separate timeslot from the "discuss deprecations" one.

[*] Assuming I'm able to register as a remote participant when it opens again

[NathanaelA]

Well, in my use case I would have totally used 'inline' if the inputs from the controllers were exposed to the XRInputSource, but apparently the implementation "standard" (why, or why not?) and on the Oculus is that the two controllers are considered non-existent to both the XRInputSource.gamepads and the standard navigator.getGamepads api's. Making the 'inline' mode useless if all you really want to do is simply show a html element fullscreen and just use the controller input's.

Instead, I'm having to wire up a massive amount of extra code, making the device do more work by copying a 2d canvas image to a 3d canvas every single frame...

I created a request detailing my issues with inline mode in #1347 with my full use case.