Hook up ui::Compositor to Display's BeginFrameSource

cc/surfaces/display.cc

 // Copyright 2014 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.
 
 #include "cc/surfaces/display.h"
 
 #include <stddef.h>
 
 #include "base/thread_task_runner_handle.h"
 #include "base/trace_event/trace_event.h"
@@ skipping 263 matching lines @@
     scheduler_->DidSwapBuffersComplete();
   if (renderer_)
     renderer_->SwapBuffersComplete();
 }
 
 void Display::CommitVSyncParameters(base::TimeTicks timebase,
                                     base::TimeDelta interval) {
   client_->CommitVSyncParameters(timebase, interval);
 }
 
+void Display::SetBeginFrameSource(BeginFrameSource* source) {
+  NOTREACHED();

[enne (OOO), 2016/03/22 21:05:18]

This is a bit awkward, but because the BrowserCompositorOutputSurface doesn't
actually participate in surfaces, it never gets this call.  Also, the
BeginFrameSource lives on OnScreenDisplayClient, which is the owner of the
Display, so it doesn't make any sense for the BrowserCompositorOutputSurface
(which also is owned by the OnScreenDisplayClient) to give an output surface
here.

Maybe this means the BeginFrameSource is in an awkward place, or we need a
better split between OutputSurfaces for surfaces and "real" OutputSurfaces, or
that maybe this is just ok.  There are already a number of other NOTREACHED
functions in Display for similar reasons, so this isn't anything new, either.

[sunnyps, 2016/03/22 21:52:44]

Can't we move the BFS from the display scheduler to display? And have the output
surface set it? There are two different BFS here - the BFS of the output surface
(backed by OS vsync signal or a synthetic one based on vsync interval/timebase)
and the BFS used for child surfaces which should be the scheduler's concern. For
the initial implementation both these could be the same.

also nit: NOTIMPLEMENTED() instead of NOTREACHED()

[enne (OOO), 2016/03/22 22:16:20]

The BFS is currently in the OnScreenDisplayClient and not the DisplayScheduler. 
I can make the BrowserCompositorOuptutSurface own the real output surface and
pass it to Display.  In that case, the Display could hand it to the
DisplayScheduler and the DisplayScheduler could register things?  I'll see how
that looks.
nit nit: I don't really plan on implementing it though, so I think it's
NOTREACHED.

+}
+
 void Display::SetMemoryPolicy(const ManagedMemoryPolicy& policy) {
   client_->SetMemoryPolicy(policy);
 }
 
 void Display::OnDraw(const gfx::Transform& transform,
                      const gfx::Rect& viewport,
                      const gfx::Rect& clip,
                      bool resourceless_software_draw) {
   NOTREACHED();
 }
@@ skipping 45 matching lines @@
 
   if (surface_id == current_surface_id_)
     UpdateRootSurfaceResourcesLocked();
 }
 
 SurfaceId Display::CurrentSurfaceId() {
   return current_surface_id_;
 }
 
 }  // namespace cc