compositor-worker: cc->blink mutation plumbing

cc/trees/proxy_main.cc

Index: cc/trees/proxy_main.cc
diff --git a/cc/trees/proxy_main.cc b/cc/trees/proxy_main.cc
index c5821f373e758d6ceb80248e639fdf2d52fa0118..02f60d7a23733dc76af5168a6c15b7faf99ddf6f 100644
--- a/cc/trees/proxy_main.cc
+++ b/cc/trees/proxy_main.cc
@@ -184,6 +184,11 @@ void ProxyMain::BeginMainFrame(
 
   current_pipeline_stage_ = ANIMATE_PIPELINE_STAGE;
 
+  if (begin_main_frame_state->begin_frame_callbacks) {
+    for (auto& callback : *begin_main_frame_state->begin_frame_callbacks)

[esprehn, 2016/03/31 05:03:11]

Why here? Why is this before 

ApplyScrollAndScale, WillBeginMainFrame, BeginMainFrame and AnimateLayers?

I'm not a cc owner, but if I was designing this I think I'd assume there was a
callback, and the consumer of cc should do the queuing and ordering of the
callbacks. This system doesn't give the mutator any control over what's going on
here.

[majidvp, 2016/03/31 19:43:03]

We want the mutations to get applied before beginning the main frame so the
new values are available in main frame before scripted animations are
serviced. It could be placed after ApplyScrollAndScale but before
BeginMainFrame.

The original design idea from piman@ was that eventually ApplyScrollAndScale
will become one of these callbacks itself and as you are suggesting proxy main
will not care about the ordering.

[danakj, 2016/04/05 17:45:21]

After ApplyScrollAndScale may make sense for now, then whatever callbacks get
registered can use what they do. Later, you'd just have to register callbacks in
the right order if you had dependencies.

But if it's meant to do things that will influence the main frame then before
BeginMainFrame makes sense. I don't see anything about ordering wrt
WillBeginMainFrame mattering right now.

+      callback.Run();
+  }
+
   layer_tree_host_->ApplyScrollAndScale(
       begin_main_frame_state->scroll_info.get());