Introduce ViewRoot forwarding input/view events to native

content/browser/renderer_host/compositor_impl_android.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 CONTENT_BROWSER_RENDERER_HOST_COMPOSITOR_IMPL_ANDROID_H_
 #define CONTENT_BROWSER_RENDERER_HOST_COMPOSITOR_IMPL_ANDROID_H_
 
 #include <stddef.h>
 
 #include <memory>
@@ skipping 110 matching lines @@
       scoped_refptr<cc::VulkanContextProvider> vulkan_context_provider,
       scoped_refptr<cc::ContextProvider> context_provider);
 
   bool HavePendingReadbacks();
   void SetBackgroundColor(int color);
 
   cc::FrameSinkId frame_sink_id_;
 
   // root_layer_ is the persistent internal root layer, while subroot_layer_
   // is the one attached by the compositor client.
+  scoped_refptr<cc::Layer> root_layer_;

[boliu, 2017/01/03 19:16:11]

this used to live in WindowAndroid? then perhaps this class should hold a
ViewRoot now instead this?

[Jinsuk Kim, 2017/01/04 10:45:02]

Compositor is shared among all content (so ViewRoot) instances. It makes sense
to use the layer in WindowAndroid but there can be multiple ViewRoots. This is
basically reverting the CL mentioned in the description.

[boliu, 2017/01/04 17:45:10]

Well.. webview doesn't use this compositor, and everywhere else, WindowAndroid
and ViewRoot is 1-to-1, so it's probably not too bad to just use ViewRoot?

I think should note this assumption in a comment here, but I think it's the
right thing to do. Plus the decision of which ViewRoot is passed here happens in
content embedder layer, it doesn't require weird logic like use the ViewRoot
from the first WebContents

[Jinsuk Kim, 2017/01/05 11:03:12]

Learned the hard way that Chrome also can have multiple ViewRoots under a
WindowAndroid when it uses overlay panel. This makes it tricky to use ViewRoot
here, because it switches dynamically depending on which content it works for,
while the root layer here means to be static, per-WindowAndroid object, created
at construction time and used it in many places with the need to update. So I'm
still not sure if it is better to switch to ViewRoot and use the underlying cc
layer. |SetRootLayer()| for instance may not work as expected if the root layer
keeps changing.

[boliu, 2017/01/05 19:09:28]

Overlay panel like contextual search? Maybe we should discuss this in the next
meeting, or just add ted to this. But in my head, I don't think an overlay panel
should get its own ViewRoot, it's just another part of a non-root subtree.. But
then again, I don't know much about overlay panels in chrome

   scoped_refptr<cc::Layer> subroot_layer_;
 
   // Subtree for hidden layers with CopyOutputRequests on them.
   scoped_refptr<cc::Layer> readback_layer_tree_;
 
   // Destruction order matters here:
   std::unique_ptr<cc::AnimationHost> animation_host_;
   std::unique_ptr<cc::LayerTreeHost> host_;
   ui::ResourceManagerImpl resource_manager_;
 
@@ skipping 27 matching lines @@
 
   gpu::Capabilities gpu_capabilities_;
   base::WeakPtrFactory<CompositorImpl> weak_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(CompositorImpl);
 };
 
 } // namespace content
 
 #endif  // CONTENT_BROWSER_RENDERER_HOST_COMPOSITOR_IMPL_ANDROID_H_