Now that restyle requests are handled by the effect, we can more easily detect
cases where we don't need to trigger a style update by looking for when the
output of the effect could actually differ.
Currently, any changes that require updates where the progress does *not* change
(e.g. pausing) are triggered by the Animation. The exception is when we
update timing properties (e.g. animation-iteration-count) from CSS but
current nsAnimationManager takes care to adjust the animation generation in
this case.
This is because rather than simply requesting a throttled restyle when there
were no properties, as of the previous patch, we no longer request a restyle at
all in this case.
We should be able to restore this optimization in bug 1235002 when we properly
encapsulate the properties of a keyframe effect.
When requesting restyles we take special care to detect when an animation has
newly finished so we perform the necessary restyle to represent the fill state.
However, we should really explicitly pull the animation off the layer at this
point by requesting a layer update. (That is, when an animation is
newly-finished we should use RestyleType::Layer instead of
RestyleType::Standard. Currently we just use RestyleType::Standard.)
In this bug we plan to move restyle requests down to the effect (since it is
the *effect* that is restyled). However, only the Animation has the notion of
"finished" or not so we detect this particular case in the Animation and
request the layer update there. We already request layer updates in the
Animation for other situations such as pausing so doing *layer* updates in the
Animation and regular restyles in the effect is not inconsistent.
This patch also tweaks test_animations_omta.html since it was previously
erroneously testing that a finished animation was still running on the
compositor.
This patch just moves a piece of functionality from
AnimationCollection::EnsureStyleRuleFor to the EffectCompositor. In subsequent
bugs we will move more and more of this functionality across until this
logic is fully contained in the EffectCompositor.
As we gradually move logic from layout/style/AnimationCommon.cpp to
dom/animation/EffectSet and EffectCompositor it makes sense to let this class
live in its own file inside dom/animation where it is used.
This is needed in order to support script-generated animations since they do not
belong to any AnimationCollection.
This patch adopts the naming "animation rule" over "style rule". Currently we
are inconsistent about this (e.g. GetAnimationRule vs EnsureStyleRuleFor).
We don't do a mass rename here but just a few places near where we're touching.
Many of the other references to "style rule" will be revised in this bug or
related bugs so we can fix those references when we come to them.
This restores the code removed in part 3 but adjusts it to iterate over
an effect set instead of an AnimationCollection. It also adds an early return
for the case where no compositor-animatable properties are found.
KeyframeEffectReadOnly::NotifyAnimationTimingUpdated currently just acts as an
alias for UpdateTargetRegistration. However, bug 1226118 added logic to
UpdateTargetRegistration which is not strictly related to updating the target
element registration. This patch tidies this up so that UpdateTargetRegistration
only does what its name suggests. This is in preparation for adding more
logic to NotifyAnimationTimingUpdated.
There are three situations when the cascade results of effects needs to be
updated.
1. The sets of effects (animations) has changed.
2. One or more effects have changed their "in effect" status.
3. Other style properties affecting the element have changing meaning that
animations applied at the animations-level of the cascade may now be
overridden or become active again.
We want to detect these situations so we can avoid updating the cascade when
none of these possibilities exist.
Currently we handle case 1 by calling UpdateCascadeResults at the appropriate
point in nsAnimationManager and nsTransitionManager when we build
animations/transtiions.
Case 2 only affects animations (since whether transitions are in effect or not
makes no difference to the cascade--they have a lower "composite order" than
animations and never overlap with each other so they can't override anything).
As a result, we handle it by adding a flag to CSSAnimation to track when an
animation was in effect last time we checked or not.
For case 3, we take care to call UpdateCascadeResults when the style context
changed in nsAnimationManager::CheckAnimationRule (called from
nsStyleSet::GetContext).
We want to generalize this detection to handle script-generated animations too.
In order to do that this patch introduces a flag to EffectSet that we will use
to mark when the cascade needs to be updated in cases 1 and 2. This patch also
sets the flag when we detect case 1. A subsequent patch sets the flag for
case 2.
Case 3 is more difficult to detect and so we simply maintain the existing
behavior of making nsAnimationManager::CheckAnimationRule unconditionally
update the cascade without checking if the "needs update" flag is set.
This is needed to ensure that the ServiceWorkerManager uses the
correct URI for non-subresource requests. Note that we're relying
on the property that non-secure non-subresource requests can never
be intercepted, so we don't need to check the request type explicitly.
- dom.vr.enabled is now "true" by default for non-release builds.
- dom.vr.add-test-devices is now "0" by default, so that content may detect
VR devices accurately.
This is needed to ensure that the ServiceWorkerManager uses the
correct URI for non-subresource requests. Note that we're relying
on the property that non-secure non-subresource requests can never
be intercepted, so we don't need to check the request type explicitly.
These two events are the leftovers for support copy/paste/cut/selectall
operations from old text_selection_dialog.js in Gaia. The code for
handling them can be removed since text_selection_dialog.js was removed
in bug 1221462.
RunExpiredTimeouts has "fudging" code to always ensure that we execute at least one timeout. This is intended to cover cases where an nsITimer fires slightly early, but it means we must be careful not to fire a timer more times than we intend to or we'll execute a timeout prematurely.
Consider a sequences of setTimeout calls alternating in delay between 0ms and 1000ms. When the 1000ms timeout fires, it schedules a 0ms timeout. The setTimeout call itself calls RescheduleTimeoutTimer, which schedules the timer for a 0 ms delay. And once we unwind the 1000ms timeout RunExpiredTimeouts will also schedule the timer for a 0 ms delay. If the timer has fired (remember, it's processed on a completely different thread) in the meantime, we ultimately will get two callbacks from nsITimer for our 0 ms timeout. The first will run the 0 ms timeout and schedule a 1000 ms timeout, and the second will run the 1000 ms timeout (remember, RunExpiredTimeouts always runs at least one timeout!) ~999 ms ahead of schedule.
The solution is to cancel the timer in RescheduleTimeoutTimer, so that when we call it the second time it will cause any pending events from the first scheduling to be canceled. But this actually doesn't work at all, because of how we use nsITimer. Before worker threads were capable of accepting arbitrary runnables we created TimerThreadEventTarget, which translates the timer firing to the special worker event queue when the timer thread attempts to *dispatch* a runnable to the worker. We still need this for some of the other types of timers (which use control runnables that interrupt JS, and not the regular event queue). But setTimeout can simply run like a normal nsITimer callback now. We need that here, or calling nsITimer::Cancel won't actually do anything, because the timer's event was ignored and TimerThreadEventTarget created its own event.
Initialize GMPStorage::mShutdown to true, so that if Init() has not completed
yet or if it failed, other methods will not try and access a null mStorage.
dom/media/ADTSDemuxer.cpp:481:10 [-Wclass-varargs] passing object of class type 'const media::TimeUnit' through variadic function
dom/media/ADTSDemuxer.cpp:513:11 [-Wclass-varargs] passing object of class type 'const media::TimeUnit' through variadic function
dom/media/ADTSDemuxer.cpp:526:14 [-Wclass-varargs] passing object of class type 'const media::TimeUnit' through variadic function
dom/media/ADTSDemuxer.cpp:527:23 [-Wclass-varargs] passing object of class type 'media::TimeUnit' through variadic function
dom/media/ADTSDemuxer.cpp:532:11 [-Wclass-varargs] passing object of class type 'const media::TimeUnit' through variadic function
dom/media/MP3Demuxer.cpp:201:10 [-Wclass-varargs] passing object of class type 'const mozilla::media::TimeUnit' through variadic function
dom/media/MP3Demuxer.cpp:237:10 [-Wclass-varargs] passing object of class type 'const mozilla::media::TimeUnit' through variadic function
dom/media/MP3Demuxer.cpp:256:13 [-Wclass-varargs] passing object of class type 'const mozilla::media::TimeUnit' through variadic function
dom/media/MP3Demuxer.cpp:257:22 [-Wclass-varargs] passing object of class type 'media::TimeUnit' through variadic function
dom/media/MP3Demuxer.cpp:262:10 [-Wclass-varargs] passing object of class type 'const mozilla::media::TimeUnit' through variadic function
We use the same logic as what is used in libvpx to ensure that we won't get a regression due to excessive memory/thread use when replacing libvpx with ffmpeg.
dom/media/DecoderTraits.cpp:314:10 [-Wunreachable-code-return] 'return' will never be executed
dom/media/DecoderTraits.cpp:324:10 [-Wunreachable-code-return] 'return' will never be executed
- dom.vr.enabled is now "true" by default for non-release builds.
- dom.vr.add-test-devices is now "0" by default, so that content may detect
VR devices accurately.
