WebVR: process animations from posted task to yield for other events

third_party/WebKit/Source/modules/vr/VRDisplay.cpp

Index: third_party/WebKit/Source/modules/vr/VRDisplay.cpp
diff --git a/third_party/WebKit/Source/modules/vr/VRDisplay.cpp b/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
index 4fa6fa737b48b1bcd283427ec31cc2e29c010de0..e6f35dc0b44df24035cbcc389ec7b77499399c8f 100644
--- a/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
+++ b/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
@@ -689,6 +689,14 @@ void VRDisplay::OnDeactivate(
       EventTypeNames::vrdisplaydeactivate, true, false, this, reason));
 }
 
+void VRDisplay::processScheduledAnimations(double timestamp) {
+  TRACE_EVENT1("gpu", "VRDisplay::OnVSync", "frame", m_vrFrameId);
+
+  AutoReset<bool> animating(&m_inAnimationFrame, true);
+  m_pendingRaf = false;
+  m_scriptedAnimationController->serviceScriptedAnimations(timestamp);
+}
+
 void VRDisplay::OnVSync(device::mojom::blink::VRPosePtr pose,
                         mojo::common::mojom::blink::TimeDeltaPtr time,
                         int16_t frameId,
@@ -711,12 +719,21 @@ void VRDisplay::OnVSync(device::mojom::blink::VRPosePtr pose,
     m_timebase = WTF::monotonicallyIncreasingTime() - timeDelta.InSecondsF();
   }
 
-  AutoReset<bool> animating(&m_inAnimationFrame, true);
   m_framePose = std::move(pose);
   m_vrFrameId = frameId;
-  m_pendingRaf = false;
-  m_scriptedAnimationController->serviceScriptedAnimations(
-      m_timebase + timeDelta.InSecondsF());
+
+  // Post a task to handle scheduled animations after the current
+  // execution context finishes, so that we yield to non-mojo tasks in
+  // between frames. Executing mojo tasks back to back within the same
+  // execution context caused extreme input delay due to processing
+  // multiple frames without yielding, see crbug.com/701444. I suspect
+  // this is due to WaitForIncomingMethodCall receiving the OnVSync
+  // but queueing it for immediate execution since it doesn't match
+  // the interface being waited on.
+  Platform::current()->currentThread()->getWebTaskRunner()->postTask(

[billorr, 2017/03/15 18:35:45]

Does this measurably have a negative effect on latency?

Should we set m_pendingVsync = false in the posted task rather than here so we
can't queue many posted tasks and get behind?

[klausw, 2017/03/15 19:00:17]

I don't think so, if I understand it right it's just saving a closure and
running it in the same thread from the work queue immediately after the current
context finishes. There's no task switching, scheduling, or IPC involved.
 
No, we're not going to be queueing multiple posted tasks. We're changing state
to indicate that we're not going to be getting another vsync because none is
scheduled. The VSync events don't happen automatically, we only get one per
GetVSync.

It gets flipped back to "pending" when the scheduled animation and its rAF
callback calls rAF which calls GetVSync.

+      BLINK_FROM_HERE,
+      WTF::bind(&VRDisplay::processScheduledAnimations,
+                wrapWeakPersistent(this), m_timebase + timeDelta.InSecondsF()));
 }
 
 void VRDisplay::ConnectVSyncProvider() {