Clarify when the reset event gets fired #637
Conversation
index.bs
Outdated
| @@ -1654,7 +1654,7 @@ A user agent MUST dispatch a <dfn event for="XRSession">selectend</dfn> event on | |||
|
|
|||
| A user agent MUST dispatch a <dfn event for="XRSession">select</dfn> event on an {{XRSession}} when one of its {{XRInputSource}}s has fully completed a [=primary action=]. The event MUST be of type {{XRInputSourceEvent}}. | |||
|
|
|||
| A user agent MUST dispatch a <dfn event for="XRReferenceSpace">reset</dfn> event on an {{XRReferenceSpace}} when discontinuities of the origin occur. (That is, significant changes in the origin's position or orientation relative to the user's environment.) It also fires when the {{boundsGeometry}} changes for a {{XRBoundedReferenceSpace}}. The event MUST be of type {{XRReferenceSpaceEvent}}, and MUST be dispatched prior to the execution of any [=XR animation frame=]s that make use of the new origin. | |||
| A user agent MUST dispatch a <dfn event for="XRReferenceSpace">reset</dfn> event on an {{XRReferenceSpace}} when discontinuities of the [=native origin=] or [=effective origin=] occur, i.e. there are significant changes in the origin’s position or orientation relative to the user’s environment. This MUST happen when the {{boundsGeometry}} changes for a {{XRBoundedReferenceSpace}}. This can also happen after the user recalibrates their XR device, or if the XR device automatically shifts its origin after losing and regaining tracking. The event MUST be of type {{XRReferenceSpaceEvent}}, and MUST be dispatched prior to the execution of any [=XR animation frame=]s that make use of the new origin. | |||
There was a problem hiding this comment.
Feels a little weird to still have "significant changes" in here when the original issue that prompted this PR highlighted that phrase in particular as under defined. That said, I don't know of a better way of describing it either (I definitely don't think we should be defining exact thresholds here) so if this is just the most sensible wording then so be it. 😉
This can also happen after...
Given the "MUST" in the previous sentence, this feels like it could be stronger. What about something like the following?
This MUST also happen when the origin shifts due to user recalibration
or after losing and regaining tracking.
There was a problem hiding this comment.
Yeah the goal here is mostly to add examples, and also to mention discontinuities.
I can add more MUSTs, I didn't because I wasn't sure if we required all this to work.
There was a problem hiding this comment.
In those particular cases I this we should require it, but you're right that those are just examples of the larger principle. They also don't apply to every platform.
I think your most recent commit is fine, but if you wanted to more explicitly frame it as an example I think that could be made clearer with a bit of reordering?
A user agent MUST dispatch a <dfn event for="XRReferenceSpace">reset</dfn>
event on an {{XRReferenceSpace}} when discontinuities of the [=native origin=]
or [=effective origin=] occur, i.e. there are significant changes in the origin’s
position or orientation relative to the user’s environment. For example, after
the user recalibrates their XR device or if the XR device automatically shifts its
origin after losing and regaining tracking. This event MUST be fired when the
{{boundsGeometry}} changes for a {{XRBoundedReferenceSpace}}. The event
MUST be of type {{XRReferenceSpaceEvent}}, and MUST be dispatched prior to
the execution of any [=XR animation frame=]s that make use of the new origin.
There was a problem hiding this comment.
ah, that's much better.
done, thanks
There was a problem hiding this comment.
Thanks for taking a stab at this, Manish! Given all the changes happening in #599, I suspect it would make more sense to land this change in the same PR... I tried to mention that, but perhaps wasn't super clear, in #559 (comment)
| @@ -1654,7 +1654,7 @@ A user agent MUST dispatch a <dfn event for="XRSession">selectend</dfn> event on | |||
|
|
|||
| A user agent MUST dispatch a <dfn event for="XRSession">select</dfn> event on an {{XRSession}} when one of its {{XRInputSource}}s has fully completed a [=primary action=]. The event MUST be of type {{XRInputSourceEvent}}. | |||
|
|
|||
| A user agent MUST dispatch a <dfn event for="XRReferenceSpace">reset</dfn> event on an {{XRReferenceSpace}} when discontinuities of the origin occur. (That is, significant changes in the origin's position or orientation relative to the user's environment.) It also fires when the {{boundsGeometry}} changes for a {{XRBoundedReferenceSpace}}. The event MUST be of type {{XRReferenceSpaceEvent}}, and MUST be dispatched prior to the execution of any [=XR animation frame=]s that make use of the new origin. | |||
| A user agent MUST dispatch a <dfn event for="XRReferenceSpace">reset</dfn> event on an {{XRReferenceSpace}} when discontinuities of the [=native origin=] or [=effective origin=] occur, i.e. there are significant changes in the origin’s position or orientation relative to the user’s environment. For example, after the user recalibrates their XR device or if the XR device automatically shifts its origin after losing and regaining tracking. This MUST happen when the {{boundsGeometry}} changes for a {{XRBoundedReferenceSpace}}. The event MUST be of type {{XRReferenceSpaceEvent}}, and MUST be dispatched prior to the execution of any [=XR animation frame=]s that make use of the new origin. | |||
There was a problem hiding this comment.
or [=effective origin=]
This doesn't seem necessary. Am I missing something?
There was a problem hiding this comment.
There have been a couple discussions in other PRs about making the origin offset something that different spaces can choose too (e.g. making the grip space an offsetted target ray space), in that case the UA may try to change the origin offset. I can remove this if you think it's unnecessary.
There was a problem hiding this comment.
It's probably fine for now. @thetuvix, when you update the spec to cover tracking loss/recovery, please revisit this text to ensure it's remained accurate.
|
@NellWaliczek, if you're OK with the verbiage is there a reason why we wouldn't want to merge this now and let #559 rebase on top of it? (And expand it, if necessary?) |
fixes #561
I'm unsure about the tracking loss example, and I've probably missed some other cases.
r? @NellWaliczek