cc: Move UI Resource management out of LayerTreeHost.

ui/compositor/compositor.h

 // Copyright (c) 2012 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.
 
 #ifndef UI_COMPOSITOR_COMPOSITOR_H_
 #define UI_COMPOSITOR_COMPOSITOR_H_
 
 #include <stdint.h>
 
 #include <memory>
@@ skipping 24 matching lines @@
 namespace base {
 class RunLoop;
 class SingleThreadTaskRunner;
 }
 
 namespace cc {
 class AnimationTimeline;
 class ContextProvider;
 class Layer;
 class LayerTreeDebugState;
-class LayerTreeHost;
+class LayerTreeHostInterface;
 class RendererSettings;
 class SharedBitmapManager;
 class SurfaceIdAllocator;
 class SurfaceManager;
 class TaskGraphRunner;
 }
 
 namespace gfx {
 class Rect;
 class ScrollOffset;
@@ skipping 353 matching lines @@
   gfx::AcceleratedWidget widget_;
 #if defined(USE_AURA)
   ui::Window* window_;
 #endif
   // A map from child id to parent id.
   std::unordered_map<uint32_t, uint32_t> surface_clients_;
   bool widget_valid_;
   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.
   scoped_refptr<CompositorVSyncManager> vsync_manager_;
 
   // The device scale factor of the monitor that this compositor is compositing
   // layers on.
   float device_scale_factor_;
 
   bool locks_will_time_out_;
   CompositorLock* compositor_lock_;
 
   LayerAnimatorCollection layer_animator_collection_;
   scoped_refptr<cc::AnimationTimeline> animation_timeline_;
 
   base::WeakPtrFactory<Compositor> weak_ptr_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(Compositor);
 };
 
 }  // namespace ui
 
 #endif  // UI_COMPOSITOR_COMPOSITOR_H_