cc/blimp: Add synchronization for scroll/scale state.

cc/trees/layer_tree.cc

Index: cc/trees/layer_tree.cc
diff --git a/cc/trees/layer_tree.cc b/cc/trees/layer_tree.cc
index 3d46e3fae10b4ccb39fac6c7b0116a0f9f1cd40c..c0d4361c55ef46bf8c2d937097340d49acd2856a 100644
--- a/cc/trees/layer_tree.cc
+++ b/cc/trees/layer_tree.cc
@@ -343,7 +343,8 @@ void LayerTree::SetPropertyTreesNeedRebuild() {
   layer_tree_host_->SetNeedsUpdateLayers();
 }
 
-void LayerTree::PushPropertiesTo(LayerTreeImpl* tree_impl) {
+void LayerTree::PushPropertiesTo(LayerTreeImpl* tree_impl,
+                                 float unapplied_page_scale_delta) {
   tree_impl->set_needs_full_tree_sync(needs_full_tree_sync_);
   needs_full_tree_sync_ = false;
 
@@ -400,9 +401,9 @@ void LayerTree::PushPropertiesTo(LayerTreeImpl* tree_impl) {
   // Setting property trees must happen before pushing the page scale.
   tree_impl->SetPropertyTrees(&property_trees_);
 
-  tree_impl->PushPageScaleFromMainThread(inputs_.page_scale_factor,
-                                         inputs_.min_page_scale_factor,
-                                         inputs_.max_page_scale_factor);
+  tree_impl->PushPageScaleFromMainThread(
+      inputs_.page_scale_factor * unapplied_page_scale_delta,

[aelias_OOO_until_Jul13, 2016/10/28 03:40:20]

Hmm, this resembles the approach I suggested for scrolling which you argued is
incorrect because it ends up applying to the transform, isn't that also the case
here?

[Khushal, 2016/10/31 21:02:01]

I did a little bit more digging, and finally landed onto exactly what's
different. Its basically how the layer tree hierarchy is mapped to property
trees and the way this is handled differently on the main thread,
https://cs.chromium.org/chromium/src/cc/trees/property_tree.h?l=208

From what I understand, in PropertyTrees, the |source_node_id| is not the same
as the transform parent id for fixed position layers. The source to parent
offset is set when updating the property tree transforms on the main thread side
to account for the layer's position, but this is disabled on the compositor
thread since no compositor thread effects would change this.

This change is working with this by updating the offsets with the deltas on the
compositor thread side property trees, which is necessary because for the scroll
offsets blink has seen, it will re-position the layers to account for them, but
the additional delta accumulated on the client main thread now has to be applied
the same way deltas are applied on the compositor thread. I guess with Spv2 if
blink is generating property trees, they should set the same hierarchy and
update them the same way for fixed position elements, the way cc does?
+ajuma since he has a lot more context on this too.

+      inputs_.min_page_scale_factor, inputs_.max_page_scale_factor);
 
   tree_impl->set_top_controls_shrink_blink_size(
       inputs_.top_controls_shrink_blink_size);