Remove XRDevice #405
Remove XRDevice #405
Conversation
|
@RafaelCintron: Nell made the excellent suggestion of ensuring you have a chance to thumbs-up the changes to context compatibility here. It's not too much different, the XRDevice is now implied rather than explicit, but I'd still appreciate you looking at it. |
explainer.md
Outdated
| * Display imagery on the device at the appropriate frame rate. | ||
| * Detect if XR capabilities are available. | ||
| * Query the XR devices capabilities. | ||
| * Poll the XR device and associate input device state. |
explainer.md
Outdated
|
|
||
| **Immersive**: Requested with the `immersive: true` dictionary argument. Immersive sessions present content directly to the `XRDevice`, enabling immersive presentation. Only one immersive session per XR hardware device is allowed at a time across the entire UA. Immersive sessions must be created within a user activation event or within another callback that has been explicitly indicated to allow immersive session creation. | ||
| Testing to see if the device supports the capabilities the application needs is done via the `navigator.xr.supportsSession` call, which takes a dictionary describing the desired functionality and returns a promise which resolves if the device can support those properties and rejects otherwise. Querying for support this way is necessary because it allows the application to detect what XR features are available without actually engaging the sensors or beginning presentation, which can incur significant power or performance overhead on some systems and may have side effects such as launching a status tray or storefront. Calling `navigator.xr.supportsSession` should also not interfere with any running XR applications on the system. |
There was a problem hiding this comment.
may have side effects such as launching a status tray or storefront
to
may have side effects such as launching a status tray, launching a storefront, or terminating another application's access to XR hardware.
|
|
||
| If an `XRDevice` is available and able to create an immersive session, the application will usually want to add some UI to trigger activation of "XR Presentation Mode", where the application can begin sending imagery to the device. Testing to see if the device supports the capabilities the application needs is done via the `supportsSession` call, which takes a dictionary of the desired functionality and returns a promise which resolves if the device can create a session which supporting those properties and rejects otherwise. Querying for support this way is necessary because it allows the application to detect what XR features are available without actually engaging the sensors or beginning presentation, which can incur significant power or performance overhead on some systems and may have side effects such as launching a status tray or storefront. | ||
| **Non-Immersive (in-page)**: The default mode, but can be explicitly requested with the `immersive: false` dictionary argument. Non-immersive content does not have the ability to display on the XR device, but is able to access device tracking information and use it to render content on the page. This technique, where a scene rendered to the page is responsive to device movement, is sometimes referred to as "Magic Window" mode. It's especially useful for mobile devices, where moving the device can be used to look around a scene. Devices like Tango phones and tablets with 6DoF tracking capabilities may expose them via non-immersive sessions even if the hardware is not capable of immersive, stereo presentation. |
There was a problem hiding this comment.
I know we don't want to change the text to inline yet because it's related to the upcoming AR mode PR.. but wow this paragraph will make a lot more sense at that point. (not asking for a change... just marveling)
explainer.md
Outdated
| Ensuring context compatibility with an `XRDevice` through either method may have side effects on other graphics resources in the page, such as causing the entire user agent to switch from rendering using an integrated GPU to a discrete GPU. | ||
| Ensuring context compatibility with an XR device through either method may have side effects on other graphics resources in the page, such as causing the entire user agent to switch from rendering using an integrated GPU to a discrete GPU. | ||
|
|
||
| If the system's underlying XR device changes (signaled by the `devicechange` event on the `navigator.xr` object) any previously set context compatibility bits will be cleared, and `makeXRCompatible` will need to be called again prior to using the context with a `XRWebGLLayer`. |
There was a problem hiding this comment.
I know we discussed this, but I can't recall where we landed... are active XRSession objects supposed to end if the devicechange event fires?
There was a problem hiding this comment.
Ok, yes, I see that below now. I wonder if it's worth mentioning something about it here too?
explainer.md
Outdated
| @@ -316,7 +294,7 @@ function onSessionEnd() { | |||
| } | |||
| ``` | |||
|
|
|||
| The UA may end a session at any time for a variety of reasons. For example: The user may forcibly end presentation via a gesture to the UA, other native applications may take exclusive access of the XR hardware device, or the XR hardware device may become disconnected from the system. Well behaved applications should monitor the `end` event on the `XRSession` to detect when that happens. | |||
| The UA may end a session at any time for a variety of reasons. For example: The user may forcibly end presentation via a gesture to the UA, other native applications may take exclusive access of the XR hardware device, or the XR hardware device may become disconnected from the system. Additionally, if the system's underlying XR device changes (signaled by the `devicechange` event on the `navigator.xr` object) any active `XRSession`s will be ended. Well behaved applications should monitor the `end` event on the `XRSession` to detect when the UA forces the session to end. | |||
There was a problem hiding this comment.
It's probably worth calling out explicitly that this applies to immersive and non-immersive equally.
| @@ -992,14 +970,6 @@ partial interface Navigator { | |||
|
|
|||
| [SecureContext, Exposed=Window] interface XR : EventTarget { | |||
| attribute EventHandler ondevicechange; | |||
There was a problem hiding this comment.
Am I missing it? Where is the Event type definition?
There was a problem hiding this comment.
There's no reason to have an XREvent, since there's only one navigator.xr object that it could possibly refer to and there's nothing else that I can think of that would be useful to communicate in this event. As a result it should just fire an Event.
This is already communicated in the spec but we've done a poor job of stating what event types should be fired in the explainer. I'll work on clarifying that.
|
Thanks Nell and Rafael! I'm presuming that anyone who's opinionated on this will have had a chance to look since the PR was announced on the call Tuesday, so I'm inclined to merge this by EOD if there's no further comments. |
Light estimation is one of the key features of AR platforms (ARCore, ARKit,...), and is essential for creating realistic AR contents. The LightEstimation of the AR platforms are tightly coupled with the "frame", because we can estimate the light of the AR scene with the environment (camera preview ) of the scene. It consists of the intensity and the color, and the Application can apply them into the intensity and the color of the ambient light. Color is optional because some platforms may support only the intensity.
Removes the concept of an XRDevice object from the spec, moving session creation to
navigator.xrdirectly. WebGL context compatibility is also updated out of necessity. This change reinforces the existing decision to have the UA select the device that will be used if multiple are present, and uses that assumption to simplify the API surface.Please note that some of the diffs in this PR look larger than they really are due to the fact that some blocks of text needed to be moved around to allow the document to read more clearly in the absence of the
XRDeviceobject.There are also some desired upcoming changes, such as supporting a Universal Rendering Path, updating session creation, or supporting an AR session type that are being studiously ignored for the sake of keeping this PR fairly targeted. This has the side effect of making it look like some parts of the API that we anticipate changing are being reinforced by this PR when in reality it's just trying to keep the document internally consistent as we update it.