NOT READY FOR REVIEW - Add support for custom animation timers.

NOT READY FOR REVIEW - Add support for custom animation timers.

This CL is incomplete, but when fleshed out, I think it will provide a very
clean way to advance animations in tests.

You can now install your own animation timer which can progress its animations
however it wants. This approach seems far superior to my previous approach,
which was to grab the last step time and manually call
AnimationContainerElement::Step on each of the animations. The main problem
being that you don't always have access to these animations, especially if they
are created implicitly.

BUG=None

[Ian Vollick, 2012-11-21 16:03:16]

Denis, what do you think of this approach?

[Denis Kuznetsov (DE-MUC), 2012-11-21 21:07:39]

This is much cleaner than my draft.
However, I had few more things in my mind:
1) Implementation of test timer that follows existing AnimationContainer
contract (e.g. upon call to Start(AnimationContainerElement* element) we expect
SetStartTime to be called on that element) we would have to duplicate most of
the AnimationContainer class anyway. So I would prefer to keep that changes
around AnimationContainer class rather than around LayerAnimator.
2) implementing this in AnimationContainer class would ease testability of other
(some bitmap?) animations that could be based on it.
3) I would prefer to have some scoped changer for test class, so that tests that
use it won't affect other tests in suite that might test "unchanged" animations.

[Ian Vollick, 2012-11-22 02:13:18]

On 2012/11/21 21:07:39, Denis Kuznetsov wrote:
> This is much cleaner than my draft.
> However, I had few more things in my mind:
> 1) Implementation of test timer that follows existing AnimationContainer
> contract (e.g. upon call to Start(AnimationContainerElement* element) we
expect
> SetStartTime to be called on that element) we would have to duplicate most of
> the AnimationContainer class anyway. So I would prefer to keep that changes
> around AnimationContainer class rather than around LayerAnimator.
I'm not against plugging a fake, test timer into the AnimationContainer. With
this CL, I was only thinking of the simplest way to advance time for
LayerAnimators in tests. If this were the only goal, I'd argue that it would be
simpler to swap out the AnimationContainer. For the LayerAnimator, the only
AnimationContainerElement method that matters is ::Step; there is no need for
::SetStartTime to be called at all. So the fake, test controller need only call
Step as required by the test. Also, there's no risk of breaking the
AnimationContainer for its other clients.

> 2) implementing this in AnimationContainer class would ease testability of
other
> (some bitmap?) animations that could be based on it.
This is a very fair point. If you think that your modifications to
AnimationContainer would be broadly useful, that's a good argument for going
that route.

> 3) I would prefer to have some scoped changer for test class, so that tests
that
> use it won't affect other tests in suite that might test "unchanged"
animations.
This could certainly be done with either approach.