1306486 - [webvr] VRDisplay.getPose and VRDisplay.getFrameData must return the same values until the next VRDisplay.submitFrame

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[:kip (Kearwood Gilbert)]

The WebVR 1.1 Spec update defines that the pose returned by VRDisplay.getFrameData() will be consistent within the frame.  We can lazily get the pose to allow for late pose prediction updates; however, once VRDisplay.getFrameData() or VRDisplay.getPose() is called, the same pose values will be returned until the next VRDisplay.submitFrame or next VRDisplay.requestPresent call.

Comment 1

[:kip (Kearwood Gilbert)]

Bug 1306427 must land first, as the patches for this bug are rebased onto the Bug 1306427 patchset.

Comment 2

[:kip (Kearwood Gilbert)]

Attachment: Bug 1306486 - Ensure that VRDisplay.getPose and VRDisplay.getFrameData return the same values until the next VRDisplay.submitFrame

Comment 3

[:kip (Kearwood Gilbert)]

Attachment: Bug 1306486 - Ensure that VRDisplay.getPose and VRDisplay.getFrameData return the same values until the next VRDisplay.submitFrame

Review commit: https://reviewboard.mozilla.org/r/85646/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/85646/

Comment 4

[Daosheng Mu[:daoshengmu]]

It looks you use mFrameInfo to keep the frame data of this current frame to be shared by VRDisplay.getPose and VRDisplay.getFrameData. I am curious that both of them have very similar behavior, even I could use VRDisplay.getFrameData instead of VRDisplay.getPose. Why do we define these two similar function? IIUC, VRDisplay.getPose is going to be deprecated, like Brandon mentioned (http://blog.tojicode.com/2016/09/update-on-webvr-spec-chrome-and-https.html).

Comment 5

[Daosheng Mu[:daoshengmu]]

(In reply to Daosheng Mu[:daoshengmu] from comment #4)
> It looks you use mFrameInfo to keep the frame data of this current frame to
> be shared by VRDisplay.getPose and VRDisplay.getFrameData. I am curious that
> both of them have very similar behavior, even I could use
> VRDisplay.getFrameData instead of VRDisplay.getPose. Why do we define these
> two similar function? IIUC, VRDisplay.getPose is going to be deprecated,
> like Brandon mentioned
> (http://blog.tojicode.com/2016/09/update-on-webvr-spec-chrome-and-https.
> html).

In this draft, https://w3c.github.io/webvr/#vrdisplay-attributes, it mentions VRDisplay.getPose would be deprecated...

Comment 6

[Daosheng Mu[:daoshengmu]]

Comment on attachment 8800822 [details]
Bug 1306486 - Ensure that VRDisplay.getPose and VRDisplay.getFrameData return the same values until the next VRDisplay.submitFrame

https://reviewboard.mozilla.org/r/85646/#review84538

::: dom/vr/VRDisplay.h:153
(Diff revision 1)
> +struct VRFrameInfo
> +{
> +  VRFrameInfo();
> +
> +  void Update(const gfx::VRDisplayInfo& aInfo,
> +    const gfx::VRHMDSensorState& aState,

They should align to "(" from the above line.

::: dom/vr/VRDisplay.h:164
(Diff revision 1)
> +
> +  gfx::VRHMDSensorState mVRState;
> +  gfx::Matrix4x4 mLeftProjection;
> +  gfx::Matrix4x4 mLeftView;
> +  gfx::Matrix4x4 mRightProjection;
> +  gfx::Matrix4x4 mRightView;

need a space

Comment 7

[Daosheng Mu[:daoshengmu]]

Comment on attachment 8800822 [details]
Bug 1306486 - Ensure that VRDisplay.getPose and VRDisplay.getFrameData return the same values until the next VRDisplay.submitFrame

https://reviewboard.mozilla.org/r/85646/#review84552

r+ from me if you fix the small marked formatting nits.

Comment 8

[:kip (Kearwood Gilbert)]

(In reply to Daosheng Mu[:daoshengmu] from comment #4)
> It looks you use mFrameInfo to keep the frame data of this current frame to
> be shared by VRDisplay.getPose and VRDisplay.getFrameData. I am curious that
> both of them have very similar behavior, even I could use
> VRDisplay.getFrameData instead of VRDisplay.getPose. Why do we define these
> two similar function? IIUC, VRDisplay.getPose is going to be deprecated,
> like Brandon mentioned
> (http://blog.tojicode.com/2016/09/update-on-webvr-spec-chrome-and-https.
> html).

We will also later remove getPose().

The use case driving the consistency of getPose() results in WebVR 1.1 is to support sites that use multiple libraries to render parts of the same page.  These libraries may not know about one another and will get the pose directly from the WebVR API.  If the poses are not consistent, then there can be some visible "wiggle" between the pieces rendered by each library.

I updated the existing functionality of getPose() to match the getFrameData() as this behavior still falls within the looser requirements of the WebVR 1.0 specification.  By keeping the behavior consistent, we can potentially remove redundant code paths in the future before removing the deprecated functions and ensure that libraries that use the old functions will render using poses that match those using the WebVR 1.1 getFrameData function.

Essentially, I wish to prepare for cases where some code has been updated to WebVR 1.1 while other code is still using the WebVR 1.0 API.

Comment 9

[:kip (Kearwood Gilbert)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3c83a34f913ad840252fba1eda31d656388179c4
Bug 1306486 - Ensure that VRDisplay.getPose and VRDisplay.getFrameData return the same values until the next VRDisplay.submitFrame,r=dmu

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3c83a34f913a