Drive SVG Animations via requestAnimationFrame

Drive SVG Animations via requestAnimationFrame

Start using FrameView::scheduleAnimation instead of a Timer for driving
the animations in a SMILTimeContainer.
The timer however remains to use when the next animation event is further
into the future than within the (~) next frame interval. Hence
SMILTimeContainer::m_timer is renamed to m_wakeupTimer.

An AnimationClock is added to SMILTimeContainer to prepare for switching
to the Document AnimationClock. The animation time from the compositor is
plumbed through the layers, and used to update said clock.

updateAnimations() is refactored to not perform frame scheduling itself,
but leave that to the caller. This is used to make any frame triggered by
the start of the timeline be scheduled using the wake-up timer instead
of the frame "tick". This is a workaround to reduce the risk of races for
simple pixel-tests (that want to sample the animation state at time 0.)

Frame scheduling is managed by a simple 3-state FSM, where one state is
used for "continuous updates" (frame driven), one is for "immediate
updates" due to timeline/interval changes. The third state is the 'Idle'
state which indicates that no frame/animation update is scheduled.

For the SVG-in-<img> (and similar) case(s),
SVGImageChromeClient::scheduleAnimation is modified to use a fixed frame
interval.
In SVGImage, the initialization of m_page is moved later, to disable any
methods that depend on accessing the SVG root element (prompted by the
need to query if the image has any animations) until the actual document
is loaded/being loaded.

BUG=231576
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=168748

[fs, 2014-03-07 17:03:22]

Round 2!

(Round 1: https://codereview.chromium.org/179293004/)

Changes since last version:
 * At timeline start, the next frame (if any) is scheduled using the timer. This
is meant to emulate the old, non-rAF, behavior, and hence avoid the flakes/fails
on various W3C*/animate-*.svg rendering tests.

 * The handling of interval-change notifications was fixed so that they schedule
a wake-up ASAP rather than just schedule a animation frame. (Makes
svg/animations/reinserting-svg-into-document.html, and probably other TCs more
stable.)

 * The above meant that the clock-freezing hacks could be dropped, which lead to
(IMHO) better looking code, and hopefully a better way forward.

I started mac_blink and win_blink in addition to the default set of try-bots,
since they seemed to be best at causing the troubles with the old version. Feel
free to start additional bots (and test it out locally.)

Happy reviewing! (And have a nice weekend.)

[pdr., 2014-03-07 18:39:25]

On 2014/03/07 17:03:22, fs wrote:
> Round 2!
> 
> (Round 1: https://codereview.chromium.org/179293004/)
> 
> Changes since last version:
>  * At timeline start, the next frame (if any) is scheduled using the timer.
This
> is meant to emulate the old, non-rAF, behavior, and hence avoid the
flakes/fails
> on various W3C*/animate-*.svg rendering tests.
> 
>  * The handling of interval-change notifications was fixed so that they
schedule
> a wake-up ASAP rather than just schedule a animation frame. (Makes
> svg/animations/reinserting-svg-into-document.html, and probably other TCs more
> stable.)
> 
>  * The above meant that the clock-freezing hacks could be dropped, which lead
to
> (IMHO) better looking code, and hopefully a better way forward.
> 
> I started mac_blink and win_blink in addition to the default set of try-bots,
> since they seemed to be best at causing the troubles with the old version.
Feel
> free to start additional bots (and test it out locally.)
> 
> Happy reviewing! (And have a nice weekend.)

I'm a happy reviewer :) I like this patch more; thanks for updating the previous
patch.

LGTM

[pdr., 2014-03-07 18:39:30]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2014-03-07 18:39:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fs@opera.com/190963003/1

[commit-bot: I haz the power, 2014-03-07 18:45:51]

Change committed as 168748