Allow inline sessions without requiring the presence of an XR device

[Manishearth]

Fixes #658, fixes #635

r? @NellWaliczek

[ddorwin]

Please see my new #635 (comment).

More generally, I wonder if the existing "XR Device" concept, which doesn't apply to inline sessions, isn't prone to such issues. @toji

[Manishearth]

Personally I feel like for inline sessions we should support a pseudo-XR device or something.

This also gives us better control over defining views; for example if your browser is running in XR, the inline session may actually want to expose two views (and then composite the canvas correctly), but the concept of a view comes from the XR device.

[toji]

I think that we probably do want to support the idea of an "inline XR device", but it's likely going to be a bit more complex than that. When the feature request API that Nell's working on lands we'll probably be in a position where developers need to declare up-front which reference spaces they want to use. If they only specify "viewer" (which seems likely to be the default) then a sensorless XR device is totally appropriate, but if the developer indicates that they want to use some level of tracking (like a "local" reference space) then we'd want to first check and see if a "real" device is available that can offer poses. I'd prefer that we see how the feature request API surface lands before diving into that, though.

In the meantime, this tweak to the spec language ensures that we get the intended behavior of inline always being supported, so I support landing it once it's been cleaned up a bit.

(Curious if @NellWaliczek has thoughts on the above?)

[Manishearth]

Addressed

[toji]

LGTM, though it appears that you've got a merge conflict that needs resolving.

I'd like to hear from @NellWaliczek before merging, though.

[Manishearth]

Rebased. I need to get better at not breaking my own PRs 😛

[NellWaliczek]

I think having a dedicated XR device that inline sessions can refer to is important for a number of reasons. Yes, there are spatial tracking implications, but also it would help clarify the difference in session behavior in a number of places.
To be honest, I'm not sure landing this PR without the broader correction is super helpful. Am I missing a reason to try to land this one as-is or can we close this in favor of an overall "add inline XR device" PR?

[NellWaliczek]

Maybe I'm missing something here... but won't this cause supportsSession('inline') to be rejected?

[Manishearth]

Fixed

[toji]

To be honest, I'm not sure landing this PR without the broader correction is super helpful. Am I missing a reason to try to land this one as-is...?

I'm assuming that we will not have an opportunity to fully address adding an inline XR device prior to the close of the June milestone, and this change would be nice to have in place to make sure our VR complete milestone demonstrates the desired behavior and gives us more leeway to update the implementation details after the fact.

[Manishearth]

I think we should land this first as a stopgap, but I can start playing with the idea of a default inline device afterwards.

[toji]

Nell asked me to do a sanity check and figure out how many places in the spec we're currently assuming an XR device will always be present when using an inline session. I have to admit, I was a bit surprised at the list:

• 1.2 Application Flow:
  • Assumes the frame loop displays images on the XR Device
• 4.1 XRSession:
  • Releasing exclusive access to the XR device.
  • Releasing graphics resources acquired by the XR device (N/A?)
  • Putting the XR device in a state that's receptive of new sessions.
  • Monitor input sources associated with the XR Device
  • Visibility state "visible" runs at refresh rate of XR device
  • Viewer reference space has list of views provided by the XR device
• 4.3 Animation Frames:
  • Animation frame runs when updates to viewer state received from XR device
• 6.1 XRSpace:
  • Native origin tracked by XR device's tracking system
• 6.2 XRReferenceSpace:
  • Reference space supported algorithm makes several references to XR device
• 7.1 XRView:
  • View corresnponds to display on XR device
  • Projection matrix provided by the underlying device
• 9.2 XRViewerPose:
  • State of the viewer as tracked by the XR device
  • Every view must be rendered to correctly display on the XR device
• 10.1 XRInputSource:
  • Input sources not associated with the XR device should not be returned
  • Input source may be removed from XR device before select is complete
• 10.2 Transient input:
  • Some XR device's support transient input sources
• 11.1 XRWebGLLayer:
  • Enabled presentation onto the XR device
  • Native framebuffer resolution matches XR device
• 11.2 WebGL context compatibility:
  • Must be compatible with XR device to display imagery
  • xrCompatible flag algorithm makes compatible with XR device
  • makeXRCompatible flag algorithm makes compatible with XR device

Mind you that's ONLY places where the text in question may be applicable to inline sessions. There's a bunch of other places where the XR device is referenced but it's only applicable to immersive sessions, or the logic presented naturally allows for avoiding interaction with the XR device, and I haven't included them here.

And after dredging all of that up, I've got to say that I'm now on Nell's side of the fence on this one. If we allow for the possibility of no XR device then there's a bunch of logic that, given a strict reading, doesn't make sense. As such the cleaner solution is likely to just full spec out an inline-only XR device that's made available in the absense of actual XR hardware.

[Manishearth]

Sounds good, will do.

[Manishearth]

#737