Further spec out when the gamepad state is updated #22
Conversation
Manishearth
force-pushed
the
gamepad-state
branch
from
fed71f6
to
a617d4d
Compare
index.bs
Outdated
| To <dfn for=XRFrame>apply gamepad frame updates</dfn> for an {{XRFrame}} |frame|, the user agent MUST run the following steps: | ||
|
|
||
| 1. For each {{XRInputSource}} with a {{XRInputSource/gamepad}} |gamepad| associated with |frame|'s {{XRFrame/session}}, perform the following steps: | ||
| 1. Update |gamepad| to reflect the gamepad state at |frame|'s [=XRFrame/time=]. |
There was a problem hiding this comment.
Is there an update algorithm we can refer to from the Gamepad API? Because this is a bit vauge. Which properties will be changed and where does the data come from?
There was a problem hiding this comment.
Nah, part of the whole problem here is that Gamepad doesn't talk about liveness at all, so this stuff is already super vague and implicit there. The gamepad spec uses the word "data" a lot instead of "state", I've changed this to use that, but it's not a dfn or used super consistently.
Once w3c/gamepad#8 is fixed we shall probably have better tools for talking about this.
index.bs
Outdated
| XRFrame {#xrframe-interface} | ||
| ------------ | ||
|
|
||
| The [=XRFrame/apply frame updates=] steps are modified to include [=apply gamepad frame updates=]. |
There was a problem hiding this comment.
Is there anything we should be doing (perhaps in the other PR) to indicate that steps from other spec documents shouldn't have any ordering dependencies on each other?
There was a problem hiding this comment.
I can add a blurb to the other PR.
Manishearth
force-pushed
the
gamepad-state
branch
from
9261e84
to
e9c4eb7
Compare
/fixes #18
It would be cleaner to spec an independent concept of "process a frame" in the webxr spec, but for now tying it to the creation of the XRFrame keeps this self-contained in this spec.
r? @NellWaliczek @toji