Added session feature handling to the explainer. #433
Conversation
|
Updated this PR so that it also fixes #417 while I'm at it, since it's closely related. |
| // TODO: Make the example feature not theoretical. | ||
| navigator.xr.requestSession({ | ||
| mode: 'immersive-vr', | ||
| desiredFeatures: ['feature-name'] |
There was a problem hiding this comment.
I've been suggesting "geoAligned" as a feature. Perhaps that would be a reasonable example? It matches the pattern almost perfectly.
There was a problem hiding this comment.
desiredFeatures: ['geoAligned']
| }).then(onSessionStarted); | ||
|
|
||
| function onDrawFrame(timestamp, xrFrame) { | ||
| if (xrFrame.featureName) { |
There was a problem hiding this comment.
see above:
if (xrFrame.geoAligned) {
|
|
||
| UAs should ideally combine any consent requests resulting from both the `desiredFeatures` and `requiredFeatures` arrays into a single request so that the user isn't, for example, shown a long series of modal consent dialogs when a session is requests that makes use of many features. | ||
|
|
||
| Finally, there are some occasions where developers may want to defer a feature request until a more contextually appropriate time. For example **(FIXME: Is there a better short-term example?)**, an `immersive-ar` application may not need access to the camera stream until the point that the user clicks a "take a photo" button, at which point a request for camera access will be less concerning for the user. For these types of situations, new features can be requested after session creation with the `requestAdditionalFeatures` method. `requestAdditionalFeatures` can only be called in response to a user activation event, and accepts an array of strings that are processed identically to the `desiredFeatures` session creation option. It returns a promise that resolves when the user has consented to or denied use of any supported features. Individual features must still be checked to see if they are available after the promise resolves. |
There was a problem hiding this comment.
Are there a list of "candidate features" anywhere? Could choose from that.
|
Overall, I like this. |
|
@blairmacintyre and @toji - we have a potential candidate feature in #374 "More general layer quality hints". In short, an app should be able to opt in to foveated renderering, but for this to work on mobile GPUs it would also have to agree to abide by restrictions that it's not allowed to rebind the output framebuffer multiple times. So maybe something like To avoid derailing this bug, can we continue discussion on this specific feature on #374 ? I added additional details there, I just wanted to mention it here as a possible candidate. |
toji
added
agenda
|
Closing because when we do revisit this issue it's likely to not have the exact solution proposed here. |
Addresses #423 and #424.
A couple of key points that aren't explicitly stated here:
requiredFrameOfReferenceTypesdictionary key alone.Finally, this PR is obviously using a "filler feature" to demonstrate the API, since we don't have any other real features decided on yet. I would like to establish this as the expected method for handling these features now, but effectively mark it as "unimplemented" until we have features that will actually make use of it. (I'd need to update the PR to show that prior to landing.)