[exp] cc: Introduce cc::CompositorMutator.

[exp] cc: Introduce cc::CompositorMutator.

BUG=

[brianderson, 2015-03-19 22:23:17]

brianderson@chromium.org changed reviewers:
+ brianderson@chromium.org

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

https://codereview.chromium.org/1014993002/diff/1/cc/scheduler/scheduler.h
File cc/scheduler/scheduler.h (right):

https://codereview.chromium.org/1014993002/diff/1/cc/scheduler/scheduler.h#ne...
cc/scheduler/scheduler.h:40: virtual void ScheduledActionCustomMutate() = 0;
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?

[loyso (OOO), 2015-03-20 02:38:14]

https://codereview.chromium.org/1014993002/diff/1/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/1014993002/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:431: shared_bitmap_manager_,
gpu_memory_buffer_manager_, compositor_mutator_,
Do we want to make CompositorMutator object shared between threads?
That would be a key design decision.

https://codereview.chromium.org/1014993002/diff/1/cc/trees/layer_tree_host_co...
File cc/trees/layer_tree_host_common.h (right):

https://codereview.chromium.org/1014993002/diff/1/cc/trees/layer_tree_host_co...
cc/trees/layer_tree_host_common.h:48: int mutated_properties;
Could you elaborate how we refer/identify properties?
How we apply updates? Thanks in advance!

[loyso (OOO), 2015-04-13 08:03:20]

loyso@chromium.org changed reviewers:
+ loyso@chromium.org

[loyso (OOO), 2015-04-13 08:03:21]

https://codereview.chromium.org/1014993002/diff/1/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/1014993002/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:448: CompositorMutator* compositor_mutator_;
JUST NOTE: This is exactly what I have here:
https://codereview.chromium.org/947033002/patch/160001/170021

1) AnimationHost is aggregated in LayerTreeHost/LayerTreeHostImpl
2) AnimationHost will eventually be decoupled via LayerTreemutators
(CompositorMutator?) abstract interface.