I may just be stubborn about changing names, but I'm not a big fan of these changes.  Maybe I don't understand what the confusion around cc::Surface is and how changing names would make that more clear.

Merging SurfaceFactory and CompositorFrameSink, sgtm.  The rest of them don't seem to make anything more clear.  FrameId seems more ambiguous than SurfaceId in the Chrome codebase.  CompositorFrameHolder sounds like a synonym of DelegatedFrameHost.

In the limit, I'm imagining most CompositorFrame-related compositing code will move out of DelegatedFrameHost, RenderWidgetHostViewChildFrame, and ui::Compositor I think because there will be one (or some small number) of "universal" CompositorFrameSink implementations. 

I actually don't like CompositorFrameHolder much either because it doesn't really describe what the purpose of the class is either but I couldn't think of a better name.

I'm not a fan of SurfaceId because you have to translate that in your head into a "reference to a CompositorFrame". I would suggest CompositorFrameId, but then what if we want to reuse those for ContentFrames?

Naming is hard... I'll leave this bug open as the official bikeshed bug for picking names for things :-D

I'll leave this open as I'm not necessarily convinced we have the naming right yet but folks haven't been complaining loudly, lately. It turns out "FrameId" is MORE confusing than "SurfaceId". A "FrameId" suggests an identifier for a single CompositorFrame as opposed to a set of sequential CompositorFrames with a common set of properties.

What we've done since I've filed this bug is cc::LocalFrameId => cc::LocalSurfaceId. Thus, cc::SurfaceId is a global identifier for a Surface, and cc::LocalSurfaceId is the component of the SurfaceId locally allocated by a frame source. FrameSinkId uniquely identifies the CompositorFrameSink.

A CompositorFrameSink doesn't correspond to a single Surface but rather a stream of surfaces scoped to a single client.

The definition of what a Surface is gets additional clarity moving forward with work on direct client-to-client resize and surface synchronization. Moving forward, a surface ID can be thought of generally as a synchronization point across clients. Within a single client, a stream of CompositorFrames on a CompositorFrameSink can be thought to be delineated by surface ID markers, as sync points can be thought to delineate a GPU command buffer stream. When a parent embeds a child's surface ID, it is saying it wants to embed any CompositorFrame within a window beginning at the point of allocation of the embedded surface ID to the point of allocation of the next surface ID.

SurfaceManager has been separated into a "SurfaceManager" and "FrameSinkManager" now.

SurfaceFactory is being eliminated in favor of a CompositorFrameSinkSupport.

I'm fairly happy with naming right now, partially because names have gotten better and partially because my mental model has gotten better.

SurfaceID is both a "sync point", and a stream of consecutive CompositorFrames that share similiar visual properties (typically size and device scale factor).