Add viewport scrollbar class to support overlay scrollbars for pinch zoom virtual viewport.

content/renderer/gpu/render_widget_compositor.h

 // Copyright (c) 2013 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_RENDERER_GPU_RENDER_WIDGET_COMPOSITOR_H_
 #define CONTENT_RENDERER_GPU_RENDER_WIDGET_COMPOSITOR_H_
 
 #include "base/memory/weak_ptr.h"
 #include "base/time.h"
 #include "cc/debug/rendering_stats.h"
@@ skipping 66 matching lines @@
                                        float new_page_scale,
                                        double duration_sec);
   virtual void setNeedsAnimate();
   virtual void setNeedsRedraw();
   virtual bool commitRequested() const;
   virtual void didStopFlinging();
   virtual bool compositeAndReadback(void *pixels, const WebKit::WebRect& rect);
   virtual void finishAllRendering();
   virtual void setDeferCommits(bool defer_commits);
   virtual void registerForAnimations(WebKit::WebLayer* layer);
+  virtual void registerPinchViewportLayers(
+      const WebKit::WebLayer* innerViewportClipLayer,
+      const WebKit::WebLayer* pageScaleLayerLayer,

[trchen, 2013/06/20 01:16:08]

nits: LayerLayer?

[wjmaclean, 2013/06/21 18:20:53]

Done.

+      const WebKit::WebLayer* innerViewportScrollLayer,
+      const WebKit::WebLayer* outerViewportScrollLayer,
+      const WebKit::WebLayer* innerViewportHorizontalScrollbarLayer,
+      const WebKit::WebLayer* innerViewportVerticalScrollbarLayer) OVERRIDE;

[trchen, 2013/06/20 01:16:08]

I feel CC is making too much assumption about the layer structure.

It looks like the main purpose of this is to allow CC to setup the scrollbar
layers. From the other thread I know that you and jamesr@ made the consensus.
Just wondering why? Is it really messy to setup the scrollbar layers from
Blink-side? Does that imply we want to setup scrollbar layers in CC for frames
and overflow:scroll as well?

[wjmaclean, 2013/06/21 18:20:53]

This is a special case for scrollbars that (1) Blink never needs to interact
with, and (2) have no associated WebCore::Scrollbar associated with them. In
particular, if we instantiate on the Blink side (as I originally proposed), then
(2) means we need additional plumbing though the compositor bindings, since we
need another pathway to create scrollbars when we don't have a backing
WebCore::Scrollbar.

[trchen, 2013/06/24 21:38:04]

Thanks for the explaination!

+  virtual void clearPinchViewportLayers() OVERRIDE;
   virtual void renderingStats(WebKit::WebRenderingStats& stats) const {}
   virtual void setShowFPSCounter(bool show);
   virtual void setShowPaintRects(bool show);
   virtual void setShowDebugBorders(bool show);
   virtual void setContinuousPaintingEnabled(bool enabled);
 
   // cc::LayerTreeHostClient implementation.
   virtual void WillBeginFrame() OVERRIDE;
   virtual void DidBeginFrame() OVERRIDE;
   virtual void Animate(double frame_begin_time) OVERRIDE;
@@ skipping 19 matching lines @@
 
   bool threaded_;
   bool suppress_schedule_composite_;
   RenderWidget* widget_;
   scoped_ptr<cc::LayerTreeHost> layer_tree_host_;
 };
 
 }  // namespace content
 
 #endif  // CONTENT_RENDERER_GPU_RENDER_WIDGET_COMPOSITOR_H_