Route D3D VSync signal to Compositor

content/browser/compositor/gpu_browser_compositor_output_surface.cc

Index: content/browser/compositor/gpu_browser_compositor_output_surface.cc
diff --git a/content/browser/compositor/gpu_browser_compositor_output_surface.cc b/content/browser/compositor/gpu_browser_compositor_output_surface.cc
index f0184f56bb33c50e00576ebe0258ee100abc4c16..b06d71d96484ffef07365f1df66eac75b742e707 100644
--- a/content/browser/compositor/gpu_browser_compositor_output_surface.cc
+++ b/content/browser/compositor/gpu_browser_compositor_output_surface.cc
@@ -44,6 +44,14 @@ GpuBrowserCompositorOutputSurface::~GpuBrowserCompositorOutputSurface() {
       UpdateVSyncParametersCallback());
 }
 
+void GpuBrowserCompositorOutputSurface::SetNeedsVSync(bool needs_vsync) {

[enne (OOO), 2017/01/24 21:32:07]

I still think this is a little bit confusing of a name.  Even when this is
false, the command buffer sends (different) vsync info back to the browser.  Do
you have some way of differentiating this "needs vsync" from the general "needs
vsync"?

Thinking out loud, is this "needs d3d vsync"? Or "needs vsync events" (vs info)?

[stanisc, 2017/01/24 22:22:40]

When D3D VSync feature is enabled that fully replaces the old vsync parameters
mechanism.
On the GPU side VSyncProvider is still invoked but only to get the vsync
interval which on windows comes from WDM, but IPC calls are not triggered by the
old mechanism anymore. We could get rid of the old mechanism entirely if we find
an accurate way to get vsync intervals. We could probably just derive them from
consecutive vsync events but I haven't implemented that yet.

+#if defined(OS_WIN)
+  GetCommandBufferProxy()->SetNeedsVSync(needs_vsync);
+#else
+  NOTREACHED();
+#endif  // defined(OS_WIN)
+}
+
 void GpuBrowserCompositorOutputSurface::OnGpuSwapBuffersCompleted(
     const std::vector<ui::LatencyInfo>& latency_info,
     gfx::SwapResult result,