Add an explicit inline XR device #737
Conversation
There was a problem hiding this comment.
Thanks for putting this together! I'm way way more comfortable with this approach than the previous direction. I only have one substantial comment and that can be easily addressed by removing the incorrect text.
Given that @toji did the initial inventory of impacted spec text, I'd like him to give this an approval as well before we merge.
index.bs
Outdated
|
|
||
| The user-agent MUST have an <dfn>inline XR Device</dfn>, which is an [=/XR Device=] that MUST [=list/contains|contain=] {{XRSessionMode/"inline"}} in its [=list of supported modes=]. The [=Inline XR Device=] will report as much pose information of the physical device the browser is rendering to as possible. | ||
|
|
||
| NOTE: On phones, the [=inline XR Device=] will report gyroscopic pose information of the phone itself. On desktops and laptops without gyroscopes, the [=inline XR Device=] will not be able to report a pose (and thus {{local}} and {{local-floor}} {{XRSpace}}s will not be [=reference space is supported|supported=]). In case the browser is already running on an [=/XR device=], the [=inline XR device=] will be the same device, and may support multiple [=view|views=]. |
There was a problem hiding this comment.
This section and the sentence above aren't actually accurate, but I can understand how you came to that conclusion because there was definitely some old cruft in the explainers on that topic. For now, just leave out any text about the reference spaces supported. In a few PRs we'll be able to land the correct text.
There was a problem hiding this comment.
Agreed with Nell here. We can patch this bit up real soon but it's better not to land something that may be misleading.
There was a problem hiding this comment.
Removed the parenthetical, but kept the "can't report pose information". Unsure what it should actually be here.
index.bs
Outdated
| - Putting the [=/XR device=] in a state such that a different source may be able to initiate a session with the same device. | ||
| - Releasing [=exclusive access=] to the [=XRSession/XR device=] if |session| is an [=immersive session=]. | ||
| - Deallocating any graphics resources acquired by |session| for presentation to the [=XRSession/XR device=]. | ||
| - Putting the [=XRSession/XR device=] in a state such that a different source may be able to initiate a session with the same device. |
There was a problem hiding this comment.
This item is also an immersive thing; multiple inline sessions can be created at the same time.
There was a problem hiding this comment.
I figure it was handwavy enough about "putting it in a state where you can request another session" since that's never not the case for inline sessions, but I made it explicit.
index.bs
Outdated
| In order for a WebGL context to be used as a source for XR imagery it must be created on a <dfn>compatible graphics adapter</dfn> for the [=/XR device=]. What is considered a [=compatible graphics adapter=] is platform dependent, but is understood to mean that the graphics adapter can supply imagery to the [=/XR device=] without undue latency. If a WebGL context was not already created on the [=compatible graphics adapter=], it typically must be re-created on the adapter in question before it can be used with an {{XRWebGLLayer}}. | ||
| In order for a WebGL context to be used as a source for immersive XR imagery it must be created on a <dfn>compatible graphics adapter</dfn> for the [=XR/immersive XR device=]. What is considered a [=compatible graphics adapter=] is platform dependent, but is understood to mean that the graphics adapter can supply imagery to the [=XR/immersive XR device=] without undue latency. If a WebGL context was not already created on the [=compatible graphics adapter=], it typically must be re-created on the adapter in question before it can be used with an {{XRWebGLLayer}}. | ||
|
|
||
| Note: On an XR platform with a single GPU, it can safely be assumed that the GPU is compatible with the [=XR/immersive XR device=]s advertised by the platform, and thus any hardware accelerated WebGL contexts are compatible as well. On PCs with both an integrated and discreet GPU the discreet GPU is often considered the [=compatible graphics adapter=] since it generally a higher performance chip. On desktop PCs with multiple graphics adapters installed, the one with the [=XR/immersive XR device=] physically connected to it is likely to be considered the [=compatible graphics adapter=]. |
There was a problem hiding this comment.
Nit, but not yours: discreet -> discrete
index.bs
Outdated
| @@ -1942,7 +1961,7 @@ Event Types {#event-types} | |||
|
|
|||
| The user agent MUST provide the following new events. Registration for and firing of the events must follow the usual behavior of DOM4 Events. | |||
|
|
|||
| The user agent MAY fire a <dfn event for="XR">devicechange</dfn> event on the {{XR}} object to indicate that the availability of [=/XR device=]s has been changed. The event MUST be of type {{Event}}. | |||
| The user agent MAY fire a <dfn event for="XR">devicechange</dfn> event on the {{XR}} object to indicate that the availability of [=XR/immersive XR device=]s has been changed. The event MUST be of type {{Event}}. | |||
There was a problem hiding this comment.
nit: not you, but should this be
The user agent MUST fire
|
Addressed |
index.bs
Outdated
|
|
||
| The user-agent MUST have an <dfn>inline XR Device</dfn>, which is an [=/XR Device=] that MUST [=list/contains|contain=] {{XRSessionMode/"inline"}} in its [=list of supported modes=]. The [=Inline XR Device=] will report as much pose information of the physical device the browser is rendering to as possible. | ||
|
|
||
| NOTE: On phones, the [=inline XR Device=] will report gyroscopic pose information of the phone itself. On desktops and laptops without gyroscopes, the [=inline XR Device=] will not be able to report a pose (and thus {{local}} and {{local-floor}} {{XRSpace}}s will not be [=reference space is supported|supported=]). In case the browser is already running on an [=/XR device=], the [=inline XR device=] will be the same device, and may support multiple [=view|views=]. |
There was a problem hiding this comment.
Agreed with Nell here. We can patch this bit up real soon but it's better not to land something that may be misleading.
index.bs
Outdated
| An [=/XR device=] has a <dfn>list of supported modes</dfn> (a [=/list=] of [=/strings=]) that [=list/contains=] "<code>inline</code>" and all the other enumeration values of {{XRSessionMode}} that the [=/XR device=] supports. | ||
| An [=/XR device=] has a <dfn>list of supported modes</dfn> (a [=/list=] of [=/strings=]) that [=list/contains=] the enumeration values of {{XRSessionMode}} that the [=/XR device=] supports. | ||
|
|
||
| The user-agent MUST have an <dfn>inline XR Device</dfn>, which is an [=/XR Device=] that MUST [=list/contains|contain=] {{XRSessionMode/"inline"}} in its [=list of supported modes=]. The [=Inline XR Device=] will report as much pose information of the physical device the browser is rendering to as possible. |
There was a problem hiding this comment.
We should indicate that the inline XR device MAY be the same as the immersive XR device, if one is present, but it's not required to be.
|
Addressed. |
Fixes #658, fixes #635
take 2 at #704
This separates the concept of immersive XR devices (which participate in selection, and can be null) from the inline XR device (a guaranteed XR device representing the device containing the screen the browser window renders to). It explicitly adds the concept of the session having an XR device so that you may have different sessions with different devices. There's a bunch of disambiguation done here to clean that up.
r? @toji @NellWaliczek
cc @ddorwin