[exp] cc: Introduce cc::CompositorMutator.

cc/scheduler/scheduler.h

Index: cc/scheduler/scheduler.h
diff --git a/cc/scheduler/scheduler.h b/cc/scheduler/scheduler.h
index 8ed584a5d49a7c6492eeef1e37043c538e1d7ecd..4e168b71926dd108e379fb6b14aea5173e954341 100644
--- a/cc/scheduler/scheduler.h
+++ b/cc/scheduler/scheduler.h
@@ -37,6 +37,7 @@ class SchedulerClient {
   virtual DrawResult ScheduledActionDrawAndSwapIfPossible() = 0;
   virtual DrawResult ScheduledActionDrawAndSwapForced() = 0;
   virtual void ScheduledActionAnimate() = 0;
+  virtual void ScheduledActionCustomMutate() = 0;

[brianderson, 2015/03/19 22:23:18]

Maybe call this ScheduledActionStartCustomMutate() to imply it's async.

In response to this, we'll need a Scheduler::NotifyCustomMutateResultsReady.

We can then use NotifyCustomMutateResultsReady to provide back-pressure on some
of the other actions we have, like PrepareTiles and the BeginImplFrameDeadline.

PrepareTiles kicks off rasterization of the visible tiles, which we won't be
able to determine until the custom mutate results are ready.

In low latency mode, this will put UIWorker directly in the critical path since
we'd have to do BeginImplFrame, raf, layout, commit, uiworker, preparetiles,
raster, activate, draw serially.

Once we have active UIWorkers though, we could run them directly from
BeginImplFrame in parallel with raf, layout, and commit. We would need to have
extra logic to run any new UIWorkers from the commit that we haven't run already
though.

I wonder if it would be acceptable to define UIWorkers as only running after the
first draw, so they don't need to be in the critical path whenever they are
added?

   virtual void ScheduledActionCommit() = 0;
   virtual void ScheduledActionActivateSyncTree() = 0;
   virtual void ScheduledActionBeginOutputSurfaceCreation() = 0;