This patch makes FlushAnimations purely responsible for posting restyles. All
ticking behavior is performed in response to an actual refresh driver tick
(currently CommonAnimationManager::WillRefresh).
We currently determine if we need refresh driver ticks when composing style
but sometimes we might not need ticks for composing style but we might need
one more tick in order to queue a final end event. Currently, this doesn't
seem to be a problem because FlushAnimations calls Animation::Tick where we
queue up events. When we remove the call to Animation::Tick from
FlushAnimations in order to make FlushAnimations purely responsible for
posting restyles, however, we will create a situation where we might mark an
animation collection as no longer needing refreshes and not simultaneously
queueing the corresponding event. If another animation collection is deleted in
the meantime we may trigger the code that causes us to disassociate from the
refresh driver and the corresponding event will never be dispatched.
Long-term (bug 1195180) we will check if it we can stop observing the refresh
driver and queue events in the same step. Until then, this patch adds a method
to detect this particular situation and uses it to avoid unregistering from
the refresh driver while we still have end events to queue.
In order to support ticking animations from their timeline we want to separate
the following two methods:
CommonAnimationManager::WillRefresh - responsible for responding to refresh
driver ticks by updating timing information and posting the necessary
pending restyles. This is the functionality we will eventually move to
Animation.
CommonAnimationManager::FlushAnimations - responsible simply for posting
pending restyles.
Currently, WillRefresh calls FlushAnimations. This patch separates the two by
copying the necessary functionality into WillRefresh. Later in this patch series
we will further separate the two by removing duplicate functionality from
FlushAnimations.
In bug 1195180 we plan to tick animations from their timeline where they
are stored in a hashtable. As a result, we will not visit them in order of
their associated target element (indeed, part of the reason we are doing
this is to support animations that do not have, or even have multiple target
elements).
The current animation mutation observer batching mechanism, however, assumes
that we visit each target element in turn and make all the necessary work at
once. In order to support visiting animations in a potentially random order
this patch reworks the animation mutation observer batching mechanism so that
it can support batching multiple elements at once.
