Introduce ViewRoot forwarding input/view events to native

content/browser/renderer_host/compositor_impl_android.h

Index: content/browser/renderer_host/compositor_impl_android.h
diff --git a/content/browser/renderer_host/compositor_impl_android.h b/content/browser/renderer_host/compositor_impl_android.h
index 506f5ccae02f84f82eb5e7e8cf32336f806c0a99..c5d376a91c7d7bbc8f015b21d5a3f54134c693c5 100644
--- a/content/browser/renderer_host/compositor_impl_android.h
+++ b/content/browser/renderer_host/compositor_impl_android.h
@@ -128,6 +128,7 @@ class CONTENT_EXPORT CompositorImpl
 
   // 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.