Pinch/Zoom Infrastructure & Plumbing CL

cc/layers/layer.h

 // Copyright 2010 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 CC_LAYERS_LAYER_H_
 #define CC_LAYERS_LAYER_H_
 
 #include <set>
 #include <string>
 
@@ skipping 251 matching lines @@
     return draw_properties_.render_surface.get();
   }
   int num_unclipped_descendants() const {
     return draw_properties_.num_unclipped_descendants;
   }
 
   void SetScrollOffset(gfx::Vector2d scroll_offset);
   gfx::Vector2d scroll_offset() const { return scroll_offset_; }
   void SetScrollOffsetFromImplSide(gfx::Vector2d scroll_offset);
 
-  void SetMaxScrollOffset(gfx::Vector2d max_scroll_offset);
-  gfx::Vector2d max_scroll_offset() const { return max_scroll_offset_; }
+  gfx::Vector2d MaxScrollOffset() const;
 
-  void SetScrollable(bool scrollable);
-  bool scrollable() const { return scrollable_; }
+  void SetScrollClipLayer(Layer* clip_layer);
+  bool scrollable() const { return scroll_clip_layer_; }

[aelias_OOO_until_Jul13, 2014/01/16 03:44:04]

Could you leave this one checking scrollable_?  It may happen due to things like
"overflow: hidden" that a normally scrollable layer is not, so we need to keep
it in a separate boolean.

[wjmaclean, 2014/01/16 15:07:32]

I would suggest that in the case of overflow:hidden we just set the clip layer
to 0.

[aelias_OOO_until_Jul13, 2014/01/16 19:49:26]

But overflow: hidden layers can still have a nonzero scroll offset, even though
they can't be gesture scrolled.  Since you're using the clip layer to compute
max scroll offset I believe this wouldn't be supported?

[wjmaclean, 2014/01/16 20:13:36]

I don't think so ... why is this behaviour needed? Is it really used? I'm just
not familiar with it.

[aelias_OOO_until_Jul13, 2014/01/16 20:21:38]

It's a web standard.  There are layout tests for it you can look around for. 
Web developers can disable user scrolling using it, while still scrolling using
Javascript to a certain place, and they do it frequently on sublayers.

[wjmaclean, 2014/01/16 20:39:41]

Ok. That being said, much of the existing code never checks max scroll offset
when doing a scroll, so this may boil down to being careful about where we do or
don't apply clamping to max scroll offset.

 
   void SetUserScrollable(bool horizontal, bool vertical);
   bool user_scrollable_horizontal() const {
     return user_scrollable_horizontal_;
   }
   bool user_scrollable_vertical() const { return user_scrollable_vertical_; }
 
   void SetShouldScrollOnMainThread(bool should_scroll_on_main_thread);
   bool should_scroll_on_main_thread() const {
     return should_scroll_on_main_thread_;
@@ skipping 275 matching lines @@
   // This pointer value is nil when a Layer is not in a tree and is
   // updated via SetLayerTreeHost() if a layer moves between trees.
   LayerTreeHost* layer_tree_host_;
 
   scoped_refptr<LayerAnimationController> layer_animation_controller_;
 
   // Layer properties.
   gfx::Size bounds_;
 
   gfx::Vector2d scroll_offset_;
-  gfx::Vector2d max_scroll_offset_;
+  // This variable indicates which ancestor layer (if any) defines the maximum
+  // scroll offset for this layer.
+  Layer* scroll_clip_layer_;

[aelias_OOO_until_Jul13, 2014/01/16 03:44:04]

Instead of having this pointer, I think we should walk up the tree to find the
nearest layer with is_container_for_fixed_position_layers_.  You can rename that
variable to is_scroll_container_ to clarify it's now used for more than fixed
position.

[wjmaclean, 2014/01/16 15:07:32]

What if we need to have a scroll layer container that is not also a fixed
container? For example, I can see this happening with the inner/outer viewports,
where only one will be a fixed position container.

[aelias_OOO_until_Jul13, 2014/01/16 19:49:26]

I propose marking both the inner and outer viewports as fixed position
containers.  It's harmless to overmark.  Basically any clip layer would have
this boolean set to true.

[wjmaclean, 2014/01/16 20:13:36]

I still don't understand ... what if we want a fixed position element to attach
to the InnerViewport? Don't these elements walk up the tree until they find a
fixed position container, which in this case would end up finding the
OuterViewport first?

[aelias_OOO_until_Jul13, 2014/01/16 20:21:38]

Web fixed-pos elements are supposed to attach to the outer viewport anyway. 
According to the doc
https://docs.google.com/a/chromium.org/document/d/1KewSqexq4Pd99RUFB-yVoUIJoc...
we already said that both inner and outer clip layers would be fixed containers.

[wjmaclean, 2014/01/16 20:39:41]

Ok, though I still think it's better to keep scroll_clip and fixed
container-ness separate (perhaps for any embedded scroll layers that a page may
have?).

   bool scrollable_ : 1;
   bool should_scroll_on_main_thread_ : 1;
   bool have_wheel_event_handlers_ : 1;
   bool user_scrollable_horizontal_ : 1;
   bool user_scrollable_vertical_ : 1;
   bool is_root_for_isolated_group_ : 1;
   bool is_container_for_fixed_position_layers_ : 1;
   bool is_drawable_ : 1;
   bool hide_layer_and_subtree_ : 1;
   bool masks_to_bounds_ : 1;
@@ skipping 38 matching lines @@
   DrawProperties<Layer> draw_properties_;
 
   PaintProperties paint_properties_;
 
   DISALLOW_COPY_AND_ASSIGN(Layer);
 };
 
 }  // namespace cc
 
 #endif  // CC_LAYERS_LAYER_H_