CC Animation: Replace AnimiationEventsVector with AnimiationEvents class.

CC Animation: Replace AnimiationEventsVector with AnimiationEvents class.

It allows us to use the forward declaration for AnimiationEvents.

This is a preparation to make AnimiationEvents an abstract class,
unknown for CC.

BUG=575053
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/e926437dd8e656f66cf83aec9823085cccf807e2
Cr-Commit-Position: refs/heads/master@{#369591}

[loyso (OOO), 2016-01-13 06:00:15]

Description was changed from

==========
CC Animation: Replace AnimiationEventsVector with AnimiationEvents class.

It allows us to use the forward declaration for AnimiationEvents.

This is a preparation to make AnimiationEvents an abstract class,
unknown for CC.

BUG=575053
==========

to

==========
CC Animation: Replace AnimiationEventsVector with AnimiationEvents class.

It allows us to use the forward declaration for AnimiationEvents.

This is a preparation to make AnimiationEvents an abstract class,
unknown for CC.

BUG=575053
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[loyso (OOO), 2016-01-13 06:01:00]

[email protected] changed reviewers:
+ [email protected], [email protected], [email protected]

[loyso (OOO), 2016-01-13 06:07:14]

On 2016/01/13 06:01:01, loyso wrote:

Alternatively, we could name it as a more general AnimationMessage to go with
message->events_ instead of events->events_.

Overall we want something like:

// Abstract Mutators message from Impl thread to Main thread.
// Visible for CC.
class MutatorsMessage {
 public:
  virtual ~MutatorsMessage() {}
}

// Higher-level message, visible in external mutators library:
class AnimationMessage : public MutatorsMessage {
 public:
  ~MutatorsMessage() override {}

 std::vector<AnimationEvent> events_;
};

[ajuma, 2016-01-13 14:21:43]

https://codereview.chromium.org/1584743002/diff/20001/cc/animation/animation_...
File cc/animation/animation_events.h (right):

https://codereview.chromium.org/1584743002/diff/20001/cc/animation/animation_...
cc/animation/animation_events.h:42: std::vector<AnimationEvent> events_;
Would it make sense to make this private, and instead provide a higher level API
for manipulating events? Otherwise other code in cc is still depending on this
being an AnimationEvent vector.

[piman, 2016-01-13 18:26:38]

ui/compositor LGTM. I haven't looked at the rest - deferring to other reviewers.

[loyso (OOO), 2016-01-13 22:44:10]

On 2016/01/13 14:21:43, ajuma wrote:
> std::vector<AnimationEvent> events_;
> Would it make sense to make this private, and instead provide a higher level
API
> for manipulating events? Otherwise other code in cc is still depending on this
> being an AnimationEvent vector.

That's the next step. In general, CC takes that message from impl-side
AnimationHost and passes it via ThreadProxy to main-thread AnimationHost.
Ideally, the only API needed for CC is how to destroy the message (virtual
dtor+scoped_ptr ownership in other words). So, see the proposed MutatorsMessage
above.

Later I want to add some sort of ThreadProxyDelegate to AnimationHost, so it can
pass that message on it's own.

[ajuma, 2016-01-13 22:56:58]

On 2016/01/13 22:44:10, loyso wrote:
> On 2016/01/13 14:21:43, ajuma wrote:
> > std::vector<AnimationEvent> events_;
> > Would it make sense to make this private, and instead provide a higher level
> API
> > for manipulating events? Otherwise other code in cc is still depending on
this
> > being an AnimationEvent vector.
> 
> That's the next step. In general, CC takes that message from impl-side
> AnimationHost and passes it via ThreadProxy to main-thread AnimationHost.
> Ideally, the only API needed for CC is how to destroy the message (virtual
> dtor+scoped_ptr ownership in other words). So, see the proposed
MutatorsMessage
> above.
> 
> Later I want to add some sort of ThreadProxyDelegate to AnimationHost, so it
can
> pass that message on it's own.

What would this ThreadProxyDelegate do? Would the actual work of cross-thread
communication still happen inside ThreadProxy?

[loyso (OOO), 2016-01-13 23:01:43]

On 2016/01/13 22:56:58, ajuma wrote:
> On 2016/01/13 22:44:10, loyso wrote:
> > Later I want to add some sort of ThreadProxyDelegate to AnimationHost, so it
> can
> > pass that message on it's own.
> 
> What would this ThreadProxyDelegate do? Would the actual work of cross-thread
> communication still happen inside ThreadProxy?

That basically would be just PostAnimationEventsToMainThreadOnImplThread method
extraction.
The actual work would happen in ThreadProxy/SingleProxy mostly.

Is it good idea to organize mutators-specific cross-thread communication entity?

[loyso (OOO), 2016-01-13 23:40:57]

FTR, this CL is mostly about proper includes. To make animation_events
dependencies visible.

[ajuma, 2016-01-14 00:02:27]

On 2016/01/13 23:01:43, loyso wrote:
> On 2016/01/13 22:56:58, ajuma wrote:
> > On 2016/01/13 22:44:10, loyso wrote:
> > > Later I want to add some sort of ThreadProxyDelegate to AnimationHost, so
it
> > can
> > > pass that message on it's own.
> > 
> > What would this ThreadProxyDelegate do? Would the actual work of
cross-thread
> > communication still happen inside ThreadProxy?
> 
> That basically would be just PostAnimationEventsToMainThreadOnImplThread
method
> extraction.
> The actual work would happen in ThreadProxy/SingleProxy mostly.
> 
> Is it good idea to organize mutators-specific cross-thread communication
entity?

It'd be good to keep the communication logic itself inside of the proxies, so
knowledge about whether the impl and main sides are on the same thread,
different threads, or different processes doesn't need to leak outside that. But
it'd be fine for PostAnimationEvents to become something more generic like
PostMutatorEvents. Is that consistent with what you have in mind?

In any case, this particular CL lgtm.

[loyso (OOO), 2016-01-14 00:14:10]

On 2016/01/14 00:02:27, ajuma wrote:
> It'd be good to keep the communication logic itself inside of the proxies, so
> knowledge about whether the impl and main sides are on the same thread,
> different threads, or different processes doesn't need to leak outside that.
But
> it'd be fine for PostAnimationEvents to become something more generic like
> PostMutatorEvents. Is that consistent with what you have in mind?
Yes, absolutely.
Also, keeping it 'as-is' (where LTH pulls AnimationHost for inter-thread
communication and AnimationHost doesn't push proxies) looks nice and simple.
Most probably we will go with abstract passive MutatorsEvents rather than with
proactive ThreadProxyDelegate.

[loyso (OOO), 2016-01-14 05:59:56]

The CQ bit was checked by [email protected]

[loyso (OOO), 2016-01-14 05:59:56]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected]
Link to the patchset: https://codereview.chromium.org/1584743002/#ps60001
(title: "Rebase.")

[commit-bot: I haz the power, 2016-01-14 06:00:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1584743002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1584743002/60001

[commit-bot: I haz the power, 2016-01-14 08:03:32]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-01-14 08:03:33]

Try jobs failed on following builders:
  linux_blink_rel on tryserver.blink (JOB_TIMED_OUT, no build URL)

[loyso (OOO), 2016-01-14 22:48:09]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2016-01-14 22:49:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1584743002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1584743002/60001

[commit-bot: I haz the power, 2016-01-14 22:55:38]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-01-14 22:56:54]

Description was changed from

==========
CC Animation: Replace AnimiationEventsVector with AnimiationEvents class.

It allows us to use the forward declaration for AnimiationEvents.

This is a preparation to make AnimiationEvents an abstract class,
unknown for CC.

BUG=575053
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
CC Animation: Replace AnimiationEventsVector with AnimiationEvents class.

It allows us to use the forward declaration for AnimiationEvents.

This is a preparation to make AnimiationEvents an abstract class,
unknown for CC.

BUG=575053
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/e926437dd8e656f66cf83aec9823085cccf807e2
Cr-Commit-Position: refs/heads/master@{#369591}
==========

[commit-bot: I haz the power, 2016-01-14 22:56:55]

Patchset 4 (id:??) landed as
https://crrev.com/e926437dd8e656f66cf83aec9823085cccf807e2
Cr-Commit-Position: refs/heads/master@{#369591}