My current inclination is we should both convert existing things to MojoCompositorFrameSink where possible (e.g. renderer, exo, OOPIFs) AND introduce a CompositorFrameSinkSupport and then try to find a path to meet in the middle and delete code. This way, we can identify corner cases in existing code and make sure we accommodate them in the new unified code path.

"convert existing things to MojoCompositorFrameSink where possible" do you mean from the client side (i.e. renderer)? Currently some of the logic to decide when to create a new surface id depends on browser-side state, so it may be non-trivial changes. We could possibly temporarily use a MojoCompositorFrameSink (as a pure interface) from the browser code, I suppose.

Yea, I was only considering this for renderer=>browser communication: offscreen canvas, top level frames, exo, OOPIF etc.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/64d953d2dbde0507b1ac81ce4768911cd870366d

commit 64d953d2dbde0507b1ac81ce4768911cd870366d
Author: fsamuel <fsamuel@chromium.org>
Date: Fri Dec 02 21:18:39 2016

Mus: Move creation of cc::Display to DisplayCompositor

What type of ContextProvider, and OutputSurface we create is a display-
compositor-specific detail and not a CompositorFrameSink specific detail.
A top-level GpuCompositorFrameSink needs a cc::Display to update the display's
surface, but it doesn't need to know how the cc::Display was set up.
This CL moves cc::Display creation to DisplayCompositor and passes in
a unique_ptr to GpuCompositorFrameSink. That way, GpuCompositorFrameSink becomes
a generic implementation that doesn't care whether an InProcessContextProvider
or some other ContextProvider was used. This will allow this code to be
reused elsewhere in Chrome.

BUG= 668126 

Review-Url: https://codereview.chromium.org/2543123004
Cr-Commit-Position: refs/heads/master@{#436023}

[modify] https://crrev.com/64d953d2dbde0507b1ac81ce4768911cd870366d/services/ui/surfaces/display_compositor.cc
[modify] https://crrev.com/64d953d2dbde0507b1ac81ce4768911cd870366d/services/ui/surfaces/display_compositor.h
[modify] https://crrev.com/64d953d2dbde0507b1ac81ce4768911cd870366d/services/ui/surfaces/gpu_compositor_frame_sink.cc
[modify] https://crrev.com/64d953d2dbde0507b1ac81ce4768911cd870366d/services/ui/surfaces/gpu_compositor_frame_sink.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/932aa65ca04713744f3166c973c19560c1faa75f

commit 932aa65ca04713744f3166c973c19560c1faa75f
Author: fsamuel <fsamuel@chromium.org>
Date: Sat Dec 03 02:38:50 2016

Extract non-Mojo bits of GpuCompositorFrameSink to CompositorFrameSinkSupport

We would like to have all Chrome clients use a single service-side
CompositorFrameSink implementation as an incremental step towards pulling the
display compositor into the gpu process. This CL extract non-mojo-specific
code from GpuCompositorFrameSink in services/ui to CompositorFrameSinkSupport
in a central place: cc/surfaces that can be used by Chrome today. Individual
clients can transition to mojo after we carefully measure the performance
impact of the transition.

BUG= 668126 , 657959
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2543373002
Cr-Commit-Position: refs/heads/master@{#436148}

[modify] https://crrev.com/932aa65ca04713744f3166c973c19560c1faa75f/cc/surfaces/BUILD.gn
[add] https://crrev.com/932aa65ca04713744f3166c973c19560c1faa75f/cc/surfaces/compositor_frame_sink_support.cc
[add] https://crrev.com/932aa65ca04713744f3166c973c19560c1faa75f/cc/surfaces/compositor_frame_sink_support.h
[add] https://crrev.com/932aa65ca04713744f3166c973c19560c1faa75f/cc/surfaces/compositor_frame_sink_support_client.h
[modify] https://crrev.com/932aa65ca04713744f3166c973c19560c1faa75f/services/ui/surfaces/gpu_compositor_frame_sink.cc
[modify] https://crrev.com/932aa65ca04713744f3166c973c19560c1faa75f/services/ui/surfaces/gpu_compositor_frame_sink.h

I am marking this as FIXED now.