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

cc/base/synced_property.h

Index: cc/base/synced_property.h
diff --git a/cc/base/synced_property.h b/cc/base/synced_property.h
index dfb33aa5ab2dfb859adeeccd652f983d693f88e2..41f4bf1ddb93edd7d7beea3f25183babc1c1e8b3 100644
--- a/cc/base/synced_property.h
+++ b/cc/base/synced_property.h
@@ -50,6 +50,17 @@ class SyncedProperty : public base::RefCounted<SyncedProperty<T>> {
     return true;
   }
 
+  // Adds the delta that has been reported to the main thread, and was expected
+  // to be reflected/resolved by the main thread in the commit, but could not
+  // be applied because it has not yet been resolved by the LayerTreeHostClient.
+  // The delta is added to the pending base so while the current value on
+  // the associated pending/active tree state simulates the result of the delta
+  // having not been applied to the main thread, but it is excluded in the
+  // subsequent deltas reported to the main thread.
+  void AddUnappliedDeltaToPendingBase(typename T::ValueType unapplied_delta) {

[aelias_OOO_until_Jul13, 2016/10/26 04:04:12]

Could this new method be avoided by applying the delta to the argument passed
into PushFromMainThread instead?

[Khushal, 2016/10/26 19:02:35]

It could, I'll just end up doing it at the calling sites using accessors.

But I actually like the fact that SyncedProperty is a nice self-contained class.
It felt like Pending/Active base were not really meant to be publicly accessible
and I just feel sad using them. 

I can change it if you prefer this logic on the outside instead.

[aelias_OOO_until_Jul13, 2016/10/27 02:09:55]

Right, I'd like to keep it self-contained and with a relatively simple data
flow, that's why I'd prefer to avoid introducing this method applying an ad hoc
mutation after the fact, if possible.  I'm not sure what you mean by "accessor",
but what I'm proposing is that you apply the mutation at an earlier time, to the
argument that gets passed into PushFromMainThread.

[Khushal, 2016/10/27 04:26:26]

Oh, I see what you mean now.

The place where PushFromMainThread happens for pushing this value to the pending
tree is here,
https://cs.chromium.org/chromium/src/cc/trees/property_tree.cc?rcl=1477524050....

The easiest way I can think of doing this there is to send a map of layer id to
delta in the reflected state instead. And query for the delta for a Layer on the
LayerTreeImpl when performing the Push.
To be honest that seems like more plumbing to me. And I think the place I'm
doing it at right now keeps it much more isolated from the code that we
generally run for state sync during the commit.
Which one do you prefer?

[Khushal, 2016/10/27 04:38:32]

Or, may be this can be done here, right before
sync_tree->UpdatePropertyTreeScrollOffset instead,
https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_in_process.cc?p....

This will be exactly before the scroll offsets are pushed to the pending tree.

[aelias_OOO_until_Jul13, 2016/10/27 07:01:31]

How about registering a did_scroll_callback that calls
cc::Layer::SetScrollOffset() with the appropriate counterscroll (similarly in 
CompositorStateDeserializer::ApplyViewportDeltas for page scale if needed)? 
That could avoid CC changes entirely I think?

Alternatively, if that doesn't work because I'm missing some nuance, I'd
consider resurrecting https://codereview.chromium.org/1385123003
scrollCompensationAdjustment.  That CC feature was small and super targeted to
the fixed-position element problem, and probably easier to reason about than yet
another layer of synced_property reflection, which is becoming a flow too
complex to keep in mind all at once.

+    pending_base_ = pending_base_.Combine(T(unapplied_delta));
+  }
+
   // Returns the difference between the last value that was committed and
   // activated from the main thread, and the current total value.
   typename T::ValueType Delta() const { return active_delta_.get(); }