cc: Move UI Resource management out of LayerTreeHost.

ui/compositor/compositor.h

Index: ui/compositor/compositor.h
diff --git a/ui/compositor/compositor.h b/ui/compositor/compositor.h
index a98e920722cd4d7535e476096a4843b86dc756a2..b19f803856d9e6d462edc7bd6687f484d11931ea 100644
--- a/ui/compositor/compositor.h
+++ b/ui/compositor/compositor.h
@@ -42,7 +42,7 @@ class AnimationTimeline;
 class ContextProvider;
 class Layer;
 class LayerTreeDebugState;
-class LayerTreeHost;
+class LayerTreeHostInterface;
 class RendererSettings;
 class SharedBitmapManager;
 class SurfaceIdAllocator;
@@ -416,7 +416,7 @@ class COMPOSITOR_EXPORT Compositor
   bool output_surface_requested_;
   std::unique_ptr<cc::SurfaceIdAllocator> surface_id_allocator_;
   scoped_refptr<cc::Layer> root_web_layer_;
-  std::unique_ptr<cc::LayerTreeHost> host_;
+  std::unique_ptr<cc::LayerTreeHostInterface> host_;

[danakj, 2016/09/08 20:58:46]

It's always an inprocess LTH for ui::Compositor, so this probably doesn't need
to point at the abstract thing?

[Khushal, 2016/09/08 22:05:24]

This is probably not decided at all, but what's going to happen with MUS? Would
that have the UI using a LayerTreeHostMUS? Just curious.

Also, is there a reason that embedders should see the impl class? I just think
it helps keep things clean because what's internal to cc remains internal, if
someone wants to do something then they have to add it to the interface and its
obvious.

[danakj, 2016/09/08 22:37:12]

If MUS was just the DisplayCompositor, it would remain an inprocess LTH, and the
OutputSurface would go OOP like in the renderer.

If MUS was putting the whole impl-side out of process, I think we'd do it at the
proxy (thats how the prototype did it for MUS again). It's possible we could
replace the LTH too, but in the end it would become concretely the other type
then, I would say it's not clear and don't worry about planning around it in
this way.
Ya I think there is. Sometimes embedders need information/things that are
specific to them, but not part of the general API, and this allows it without
casting or something. Example:
https://cs.chromium.org/chromium/src/content/common/gpu/client/context_provid...
this doesn't need to be part of the general API since all users of it know the
concrete type.

[Khushal, 2016/09/08 23:56:05]

Okay, sounds good.
The pattern that I was seeing was that with the LayerTreeHost we avoided things
like that(for instance with stuff that's in threaded or single threaded mode
only) by adding it to the API and just commenting that it is not supported in
that mode (I looked at CompositeImmediately etc.) but if that's not necessary,
then that's awesome. Makes my change simpler. :D
Removed those bits.

   scoped_refptr<base::SingleThreadTaskRunner> task_runner_;
 
   // The manager of vsync parameters for this compositor.