Now that CompositorFrameSinkSupport has landed, it might make sense to go in the opposite direction: Use CompositorFrameSinkSupport first, then transition to mojo.

I should add some more detail on the intended goal here as it isn't clear from the bug description. Ultimately, DelegatedFrameHost, will go away, and be replaced by components/display_compositor/gpu_offscreen_compositor_frame_sink.{cc|h} and friends but we need to make sure we have the right CompositorFrameSink and DisplayCompositor API to accommodate all the functionality in there.

Some currently missing functionality includes"

1. Copy requests
2. Frame eviction
3. CompositorLock

All of these are currently being actively worked on. Once complete, it ought to be trivial to use CompositorFrameSinkSupport in DelegatedFrameHost and ultimately (separately) replace DelegatedFrameHost with GpuOffscreenCompositorFrameSink

Now that there is GpuCompositorFrameSink. And renderer will submit frame data into GPU process directly.  Why DelegatedFrameHost is required?

Chrome running in Mus+Ash uses GpuCompositorFrameSink, but Chrome outside of Mus+Ash uses DelegatedFrameHost. GpuCompositorFrameSink is incomplete and Mus+Ash is still behind a flag and so it's not used it production. In order to validate the new API, and verify correctness and mojo serialization performance in isolation from the rest of the Mus+Ash changes, I am proposing here that we refactor DelegatedFrameHost to look like GpuCompositorFrameSink, add additional functionality to GpuCompositorFrameSink as need be, and then ultimately replace DelegatedFrameHost with GpuCompositorFrameSink on all platforms.

RendererCompositorFrameSink is gone. DelegatedFrameHost is being replaced by code that will run out of process/thread from the browser process, rather than implement a CompositorFrameSink.