Make --disable-gpu-vsync work with CoreAnimation

content/browser/renderer_host/compositing_iosurface_layer_mac.mm

Index: content/browser/renderer_host/compositing_iosurface_layer_mac.mm
diff --git a/content/browser/renderer_host/compositing_iosurface_layer_mac.mm b/content/browser/renderer_host/compositing_iosurface_layer_mac.mm
index 2f2068e036206867b0871d5cadec9b016ecd0121..60d77176923db9b5352a55672f7bf373be2b449e 100644
--- a/content/browser/renderer_host/compositing_iosurface_layer_mac.mm
+++ b/content/browser/renderer_host/compositing_iosurface_layer_mac.mm
@@ -57,11 +57,22 @@
 }
 
 - (void)gotNewFrame {
-  if (![self isAsynchronous]) {
+  if (context_ && context_->is_vsync_disabled()) {
+    // If vsync is disabled, draw immediately and don't bother trying to use
+    // the isAsynchronous property to ensure smooth animation.
     [self setNeedsDisplay];
-    [self setAsynchronous:YES];
+    [self displayIfNeeded];
+
+    // Calls to setNeedsDisplay can sometimes be ignored, especially if issued
+    // rapidly (e.g, with vsync off). This is unacceptable because the failure
+    // to ack a single frame will hang the renderer. Ensure that the renderer
+    // not be blocked.
+    if (needsDisplay_)
+      renderWidgetHostView_->SendPendingSwapAck();

[Ken Russell (switch to Gerrit), 2014/02/20 23:01:53]

If we're mostly sending swap acks upon receiving new frames (gotNewFrame,
timerSinceGotNewFrameFired), is it still necessary to do so inside
CompositorSwapBuffers, which is after the frame is processed (if I remember
correctly)?

Should the code be consistent about where the swap acks are sent? If the system
is fragile to even one lost swap ack, then it seems to me that we should ack
upon receipt of each frame, and never when it's actually processed, if frames
can be dropped by Core Animation for throttling purposes.

[ccameron, 2014/02/21 00:48:23]

CompositorSwapBuffers only does the ack if the frame will not be drawn (it's
hidden, the window is 0x0 in size, etc). CompositorSwapBuffers will not do the
ack if the frame is expected to be drawn -- it will wait for the actual draw
function to complete before doing the ack.
The acks are the mechanism through which the browser can signal back-pressure to
the renderer. I asked brianderson and nduca about this, because it would require
less thought to just ack immediately and communicate backpressure in some way
that would consistently drop the renderer, back to 30fps (for example).

I trust isAsynchronous:YES to always get called in short order (if it doesn't,
we have all sorts of serious issues).

I don't trust setNeedsDisplay, and so I always do the
setNeedsDisplay+displayIfNeeded+ackIfNotDisplayed triplet. This happens in two
cases -- (1) vsync-disabled, which is not-optimal-user-experience territory and
(2) the edge case where you happen to drop out of animating mode while a frame
is pending, a case that will only happen if you somehow suspend the run loop for
a second at the exact wrong moment (highly unlikely, but could happen in
theory).

   } else {
     needsDisplay_ = YES;
+    if (![self isAsynchronous])
+      [self setAsynchronous:YES];
   }
 }
 
@@ -70,8 +81,15 @@
     return;
 
   [self setAsynchronous:NO];
-  if (needsDisplay_)
+
+  // If there was a pending frame, ensure that it goes through.
+  if (needsDisplay_) {
     [self setNeedsDisplay];
+    [self displayIfNeeded];
+  }
+  // If that fails then ensure that, at a minimum, the renderer is not blocked.
+  if (needsDisplay_)
+    renderWidgetHostView_->SendPendingSwapAck();
 }
 
 - (void)waitForResizedFrameInContext:(CGLContextObj)glContext {
@@ -178,6 +196,11 @@
 
   needsDisplay_ = NO;
   renderWidgetHostView_->SendPendingLatencyInfoToHost();
+
+  [super drawInCGLContext:glContext
+              pixelFormat:pixelFormat
+             forLayerTime:timeInterval
+              displayTime:timeStamp];
 }
 
 @end