Remove Sync GetPose VRService call, implement VRVSyncProvider

device/vr/vr_service.mojom

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file.
 
 module device.mojom;
 
 // A field of view, given by 4 degrees describing the view from a center point.
 struct VRFieldOfView {
   float upDegrees;
   float downDegrees;
   float leftDegrees;
@@ skipping 66 matching lines @@
   SetClient(VRServiceClient client) => (uint32 numberOfConnectedDevices);
   // Inform the service that the page is listening for vrdisplayactivate events.
   SetListeningForActivate(bool listening);
 };
 
 interface VRServiceClient {
   OnDisplayConnected(VRDisplay display, VRDisplayClient& request, VRDisplayInfo displayInfo);
 };
 
 interface VRDisplay {
-  [Sync]
-  GetPose() => (VRPose? pose);
   ResetPose();
 
   RequestPresent(bool secureOrigin) => (bool success);
   ExitPresent();
   SubmitFrame(VRPose? pose);
   UpdateLayerBounds(VRLayerBounds leftBounds, VRLayerBounds rightBounds);
+  GetVRVSyncProvider(VRVSyncProvider& request);

[dcheng, 2017/01/12 09:56:56]

Out of curiosity, why a separate interface?

[mthiesse, 2017/01/12 15:49:03]

We bind to the VRVSyncProvider on a separate thread with a separate task runner
from the VRDisplay (sometimes).

There are two VRVSyncProvider implementations, the non-presenting implementation
that lives in the UI thread, and the presenting implementation that lives in the
GL thread (both live in the browser process though).

Let me know if I'm missing an obviously better approach.

[dcheng, 2017/01/14 11:22:52]

The one thing to watch out for is there won't be any ordering guarantees between
VRDisplay and VRSyncProvider (unless you make them associated). I'm not familiar
enough with WebVR to say if that's a requirement here.

[mthiesse, 2017/01/16 20:52:57]

Oh, yes I was careful to make sure ordering isn't an issue.

+};
+
+interface VRVSyncProvider {
+  GetVSync() => (VRPose? pose, double time_seconds);

[dcheng, 2017/01/12 09:56:56]

Is it possible to use mojo.common.mojom.TimeTicks here?

(I think we might need to add a Blink typemap though...)

[mthiesse, 2017/01/12 15:49:03]

Would using TimeDelta be okay? I should probably add a comment explaining this,
but the code currently assumes that the VSync provider and the blink have
different timebases (whether or not they do in practice I don't actually know),
so time_seconds is just treated as a delta from the first VSync received.


Alternatively, I could make sure the timebases are the same and use TimeTicks...
Are WTF::monotonicallyIncreasingTime() and base::Timeticks::Now guaranteed to be
the same?

[dcheng, 2017/01/14 11:22:52]

I'm honestly not sure. I know CC sends around TimeTicks, but I don't know  how
these TimeTicks are used...

Given that we're using this as a delta, TimeDelta seems fine. We can
independently figure out the TimeTicks issue.

[mthiesse, 2017/01/16 20:52:57]

Done?

Sidenote, figuring out I had to include "//mojo/common:common_custom_types", to
the mojo deps was really confusing, because it generated mojom.h files without
complaint, but the callback asked for a  mojo::common::mojom::TimeDeltaPtr
instead of a base::TimeDelta, and I wasn't able to construct a TimeDeltaPtr.
Very surprising behavior that changing the deps changed the generated code.

 };
 
 interface VRDisplayClient {
   OnChanged(VRDisplayInfo display);
   OnExitPresent();
   OnBlur();
   OnFocus();
   OnActivate(VRDisplayEventReason reason);
   OnDeactivate(VRDisplayEventReason reason);
 };