Plumb PinchVirtualViewport layers into CC.

content/renderer/gpu/render_widget_compositor.cc

Index: content/renderer/gpu/render_widget_compositor.cc
diff --git a/content/renderer/gpu/render_widget_compositor.cc b/content/renderer/gpu/render_widget_compositor.cc
index cb7df844a6d1de53328c91d0022abc81d18cb46e..9b22e2bb57f4806e38e423a09622da4b2e4e96cc 100644
--- a/content/renderer/gpu/render_widget_compositor.cc
+++ b/content/renderer/gpu/render_widget_compositor.cc
@@ -489,6 +489,27 @@ void RenderWidgetCompositor::registerForAnimations(WebKit::WebLayer* layer) {
       layer_tree_host_->animation_registrar());
 }
 
+void RenderWidgetCompositor::registerPinchViewportLayers(
+    const WebKit::WebLayer* innerViewportClipLayer,

[enne (OOO), 2013/09/10 17:03:04]

I understand setting the inner and outer viewport scroll layers, as you'll need
this to figure out what the total scroll offset is at certain points in LT(H)I.

I'm a little bit less sure about what the inner viewport clip layer is for.  I
assume you're going to use this to hook up to the solid color scrollbars to help
eliminate the UpdateSolidColorScrollbars function?  How are you going to find
them?  For these "pinch-aware" solid color scrollbars, could you set the clip
layer explicitly on them?

[wjmaclean, 2013/09/11 00:19:25]

Actually, the clip layer probably does not need to be passed at all (though the
original intent was likely as you indicate). The existing code in
tree_synchronizer that notifies scroll layers about their scrollbars should work
fine for the inner-viewport solid-color scrollbars, and my idea was that the
scroll layer would look after transmitting the necessary information to the
scroll bars, as per the current model. In that way the mechanism for pushing
information to the scrollbars won't be specific to inner/out viewport (or any
other scroll-layer type). But each scroll layer would need to know its clip
layer; I had intended this would be set (in a later cl) in LayerTreeHost.

[enne (OOO), 2013/09/11 00:49:46]

Yeah, I was thinking something along those lines too, that the clip layer would
have to be set on the scroll layer (or scroll bar, maybe?), although maybe from
Blink and not right in LayerTreeHost since that's where the clip layer is
established.

[wjmaclean, 2013/09/11 17:30:37]

Hmm, ok ... if we're setting this on the Blink side, does adding something like
WebLayer::setScrollClipLayer() seem ok? Then we can plumb the pointer through on
the CC-side.

+    const WebKit::WebLayer* pageScaleLayerLayer,

[enne (OOO), 2013/09/10 17:03:04]

I'd like it if this patch could help make parts of the non-pinch viewport path
be more explicit, and also unify the way both of these paths work so that we
have fewer conditional paths in the compositor.

Is it possible to have both paths go through this? In particular, it seems both
paths need the page scale layer?  Also, it seems like both paths could set inner
viewport scroll layer (as root scroll layer for the non-pinch viewport path)
with outer viewport scroll layer being the only optional layer here.

[wjmaclean, 2013/09/11 00:19:25]

Hmm, ok. I guess I was still operating on the principle of keeping all the pinch
stuff isolated, at least until all the bits have landed, and we feel it's
working correctly.
I'm not quite sure how we would run both code paths through here, since most of
this doesn't exist if the non-pinch pathway is used. We could presumably find
the root scroll layer and pass pointers to it and its parent (to avoid the need
to discover these in LayerTreeHost), does that sound helpful? The rest of the
layer pointers would be 0 in the non-pinch case.

Does that sound reasonable?

[enne (OOO), 2013/09/11 00:49:46]

If you want to keep it separate as an intermediate step, that's fine.  I'm just
looking for an eye to how this will look eventually, and when I see stuff like
"if pinch use this layer and if not use this other layer" in this patch, that
code seems like it could go away eventually.
You said above that you're thinking of removing the clip layer.  So, that leaves
page scale and the two scroll layers.  The non-pinch case has a page scale layer
and one scroll layer.  So, if by "most of this" you mean "one of the scroll
layers", then yes?

But, yes.  I think this would eventually just become RegisterViewportLayers, and
the other path could use it to set up some layer relationships that are
currently implicitly discovered from the tree itself.

[wjmaclean, 2013/09/11 17:30:37]

Done.

I've renamed the WebLayerTreeView interface function to just be
registerViewportLayers(), and this now gets called in both paths. Perhaps in
some not-too-distant future, when the pinch work has stabilized, we can
re-factor PinchViewports into something like "ViewportManager", and move some of
the logic out of WebViewImpl::setRootGraphicsLayer().

+    const WebKit::WebLayer* innerViewportScrollLayer,
+    const WebKit::WebLayer* outerViewportScrollLayer) {
+  layer_tree_host_->RegisterPinchViewportLayers(
+      static_cast<const webkit::WebLayerImpl*>(innerViewportClipLayer)->layer(),
+      static_cast<const webkit::WebLayerImpl*>(pageScaleLayerLayer)->layer(),
+      static_cast<const webkit::WebLayerImpl*>(innerViewportScrollLayer)
+          ->layer(),
+      static_cast<const webkit::WebLayerImpl*>(outerViewportScrollLayer)
+          ->layer());
+}
+
+void RenderWidgetCompositor::clearPinchViewportLayers() {
+  layer_tree_host_->RegisterPinchViewportLayers(scoped_refptr<cc::Layer>(),
+                                                scoped_refptr<cc::Layer>(),
+                                                scoped_refptr<cc::Layer>(),
+                                                scoped_refptr<cc::Layer>());
+}
+
 bool RenderWidgetCompositor::compositeAndReadback(
     void *pixels, const WebRect& rect_in_device_viewport) {
   return layer_tree_host_->CompositeAndReadback(pixels,