Bug 1178834: IonMonkey - Always lazy link code, r=jandem

Revert "Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson" This reverts commit d05f091bf4d8#l1.25

Bug 1188251 part 8 - Remove call to Animation::Tick from CheckAnimationRule; r=dholbert We want to move the newly-introduced RequestRestyle call from FlushAnimations to Animation::Tick. However, nsAnimationManager::CheckAnimationRule calls Animation::Tick so this would cause us to start posting animation restyles within a restyle. Typically, Animations have an effect (currently there is only one type of effect: KeyframeEffectReadOnly) and when there is any change in timing they pass it down to their effect. However, the Animation is dependent on the duration of the effect for determining if it is "finished" or not. As a result, when an effect's timing changes, the owning Animation needs to know. (The way this *should* work is that effects should tell their animation or trigger some chain of events that causes animation's to update themselves. However, the current implementation of effects is fairly primitive and does not do this or even have a reference to the owning Animation. When we implement the script API for updating the timing properties of effects we will have to fix this but for now it is up to code in layout/style to update the Animation when it touches the corresponding effect's timing.) nsAnimationManager::CheckAnimationRule currently does this by calling Animation::Tick() which ensures the Animation's finished state is updated accordingly. Ultimately we want to ensure that Animation::Tick is called exactly once per frame (and at the appropriate point in that frame) so we'd like to remove this call from CheckAnimationRule. This patch achieves that by: * Making Animation::SetEffect update the animation's timing - this is necessary for animations that are created by CheckAnimationRule and will be necessary when once we make Animation.effect writeable from script anyway. * Calling Animation::SetEffect even for the case when we are updating the existing effect. Another side-effect of calling Animation::Tick within nsAnimationManager::CheckAnimationRule is that CSSAnimation::Tick queues events. There are some tests (e.g. layout/style/test/test_animations.html) that assume that animationstart events are dispatched immediately when new animations are created. That will change with bug 1134163 but for now we should maintain this existing behavior since changing this might introduce compatibility issues that are best dealt with as a separate bug rather than blocking this refactoring. To that end, this patch also explicitly queues animationstart events for newly-created animations.

Bug 1188251 part 7 - Move WillRefresh to CommonAnimationManager; r=dholbert nsTransitionManager::WillRefresh and nsAnimationManager::WillRefresh are now identical and all methods they call exist on CommonAnimationManager so we can unify them there.

Bug 1188251 part 6 - Unify FlushAnimations and FlushTransitions; r=dholbert The implementations of FlushAnimations and FlushTransitions should now be all but equivalent so this patch combines them into a single implementation on CommonAnimationManager. Regarding some of the minor differences between the two methods: * The combined implementation drops the check for an empty list of collections found only in FlushTransitions. This seems like a very minor optimization that could possibly cause us to fail to unregister from the refresh driver if we forgot to do so when removing the last collection. * The combined implementation uses the loop implementation from FlushAnimations since it is more compact. This patch also removes the extra nested scope since it doesn't seem necessary.

Bug 1188251 part 5 - Move some assertions from FlushTransitions to RequestRestyle; r=dholbert There are a couple of assertions that only exist in FlushTransitions (and not FlushAnimations). This patch moves them to RequestRestyle since they appear to apply to either transitions or animations equally. By eliminating this difference between FlushTransitions and FlushAnimations we should then be in a position to combine them into a common method on the base class.

Bug 1188251 part 4 - Move throttling checks to AnimationCollection::RequestRestyle; r=dholbert This patch moves the additional checks (beyond those of Animation::CanThrottle) from FlushAnimations/FlushTransitions to AnimationCollection::RequestRestyle. These checks are on a per-collection basis hence it makes sense for the collection to perform them. This also moves logic out of the managers which is needed if we want to support script-based animations without introducing another manager.

Bug 1188251 part 3 - Add AnimationCollection::RequestRestyle; r=dholbert Ultimately we want to move throttling logic to AnimationCollection and Animation::Tick (and later to KeyframeEffect::SetParentTime). This is so that we can support script-generated animations without having to introduce yet another manager. To that end this patch introduces a method on AnimationCollection that can be called from Animation::Tick to perform the necessary notifications needed to update style. Later in this patch series we will extend RequestRestyle to incorporate more of the throttling logic and further extend it to cover some of the other notifications such as updating layers. This patch tracks whether or not we have already posted a restyle for animation to avoid making redundant calls. Calls to nsIDocument::SetNeedStyleFlush are cheap and more difficult to detect when they have completed so we don't filter redundant calls in the Restyle::Throttled case. If mHasPendingAnimationRestyle is set and AnimationCommon::EnsureStyleRuleFor is *never* called then we could arrive at situation where we fail to make post further restyles for animation. I have verified that if we fail to reset mHasPendingAnimationRestyle at the appropriate point (e.g. resetting it at the end of EnsureStyleRuleFor *after* the early-returns) then a number of existing tests fail. Furthermore, I have observed that it is reset by the beginning of each tick in almost every case except for a few instances of browser mochitests such as browser/components/customizableui/test/browser_1007336_lwthemes_in_customize_mode.js. In this case, during the async cleanup of the test, we have an opacity transition on a vbox element that becomes display:none and appears to be skipped during restyling. However, even in this case, EnsureStyleRuleFor is called within one or at most two ticks and mHasPendingAnimationRestyle flag is cleared (i.e. it does not get stuck).

Bug 1188251 part 2 - Check if a tick can be throttled in FlushAnimations using Animation::CanThrottle; r=dholbert In FlushTransitions and FlushAnimations we use different mechanisms to see if a transition/animation can be throttled on the current tick. FlushTransitions calls Animation::CanThrottle whilst FlushAnimations calls EnsureStyleRuleFor and checks if the rule has changed or not. These are not as completely different as they might seem at first since, internally, EnsureStyleRuleFor calls Animation::CanThrottle. We would like to unify this behavior and simply use Animation::CanThrottle in FlushAnimations as we do in FlushTransitions. First, however, we have to account for the differences in these approaches: 1. Using the result of EnsureStyleRuleFor means we may *not* call PostRestyleForAnimation if an animation collection's mNeedsRefreshes member is false. This member is false when all animations have finished (or there are no animations in the collection). In this case EnsureStyleRuleFor will not update the style rule and we will end up assuming the tick can be throttled. *However*, in the case that all animations are finished Animation::CanThrottle will *also* return true (technically it will return false until we compose style for the first time after becoming finished but beyond that one moment it will return true) so skipping this check by using Animation::CanThrottle instead of EnsureStyleRuleFor should not make a significant difference. 2. Using the result of EnsureStyleRuleFor will mean that if we have already updated the style rule within a given tick we will avoid calling PostRestyleForAnimation (and call SetNeedStyleFlush instead). This can happen the first time we call FlushAnimations from PresShell::FlushPendingNotifications. (When we call FlushAnimations from nsAnimationManager::WillRefresh mStyleRuleRefreshTime will be stale and we won't apply this optimization. Furthermore after the first call to PresShell::FlushPendingNotifications we will typically skip calling FlushAnimations since PresShell::StyleUpdateForAllAnimationsIsUpToDate will typically return true). This seems like a possibly useful optimization although it is surprising we don't do the same for transitions. Note that this optimization applies regardless of whether we are performing a throttleable flush or not. That is, even if we pass CommonAnimationManager::Cannot_Throttle we will still end up throttling the tick in this case. Furthermore, we will mark the document as needing a style flush even though this does not appear to be necessary. This patch copies this optimization (checking if mStyleRuleRefreshTime) to FlushAnimations so we can maintain this behavior when calling Animation::CanThrottle instead of EnsureStyleRuleFor. It also applies the same behavior to FlushTransitions for consistency (and so we can later combine FlushAnimations and FlushTransitions). Note that we apply this optimization *before* calling Tick since it should only apply once we have already Tick'ed the animations in the collection. We will first hit FlushAnimations as a result of the refresh driver calling nsAnimationManager/nsTransitionManager::WillRefresh at which point mStyleRuleRefreshTime should be stale. Using this order not only saves redundant work but also makes moving the restyle code to Animation later on more straightforward. (In future we will divorce WillRefresh and FlushAnimations and only call Tick in WillRefresh and only perform this optimization FlushAnimations.) 3. Using the result of EnsureStyleRuleFor means that while checking if we can throttle or not we also update the style rule in FlushAnimations. That seems like an odd side-effect particularly since FlushTransitions doesn't do the same thing.

Bug 1188251 part 1 - Remove transitions cleanup from FlushTransitions; r=dholbert There is no longer anything in FlushTransitions that modifies the set of transitions. I believe this changed as of bug 960465, specifically changeset https://hg.mozilla.org/mozilla-central/rev/b2ee72589c18, so that this code is no longer needed. By removing this we can further align FlushAnimations and FlushTransitions.

Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson

bug 1191889 skip Close() when not initialized r=roc

bug 962719 remove unnecessary OneIteration() parameters aFrom/aTo r=padenot

bug 962719 remove notified blocked warning of finished stream r=padenot Finished can be determined immediately after mFinished is set, but blocked is not determined until RecomputeBlocking() has run.

bug 962719 update stream state to processed time after processing r=padenot Notifications are now up to date with processing, and MediaStream::GetCurrentTime() now returns "the main-thread's view of how much data has been processed by this stream", as documented.

bug 962719 provide video frames to the container as soon as available r=roc This does not affect the target time of the video frames, but may mean that more frames are displayed.

bug 1194558 correct time conversion for video frame timestamps r=roc MediaTimeToSeconds() works fine for negative intervals

bug 962719 provide frame ID service to clients r=roc

bug 962719 make FindChunkContaining() public r=roc

bug 962719 introduce mProcessedTime r=padenot