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
Review URL: https://codereview.chromium.org/190963003
git-svn-id: svn://svn.chromium.org/blink/trunk@168748 bbb929c8-8fbe-4397-9dbb-9b2b20218538
9 files changed
