8cbb80c89aefa630ac067191b17d5e2a67bb43d2: Bug 1188251 part 6 - Unify FlushAnimations and FlushTransitions; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 258000
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.
754717f00c5e1f31fde952cd96a0680c20b7c64e: Bug 1188251 part 5 - Move some assertions from FlushTransitions to RequestRestyle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257999
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.
ae2c4fad97a0b41f71364091cfe1cfc9dbd9eae3: Bug 1188251 part 4 - Move throttling checks to AnimationCollection::RequestRestyle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257998
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.
eb67f47a146dc79c39cbffab9e522288901be911: Bug 1188251 part 3 - Add AnimationCollection::RequestRestyle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257997
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).
6bb23d47f4694dc552469db17a3db180e266d3e9: Bug 1188251 part 2 - Check if a tick can be throttled in FlushAnimations using Animation::CanThrottle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257996
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.
0924d8ec4bd78dacd5f01970fb9a2941fbe66cf8: Bug 1188251 part 1 - Remove transitions cleanup from FlushTransitions; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257995
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.
d05f091bf4d8d28c789e27a122bc9bfc096e8d63: Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Aug 2015 08:55:39 +1000 - rev 257994
Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson
c95b78847e3c140a094f019b5c58f0830cec2c65: bug 1191889 skip Close() when not initialized r=roc
Karl Tomlinson <karlt+@karlt.net> - Mon, 17 Aug 2015 10:07:50 +1200 - rev 257993
bug 1191889 skip Close() when not initialized r=roc
c790c2fe70dafd681810f7b592113a029c290220: bug 962719 remove unnecessary OneIteration() parameters aFrom/aTo r=padenot
Karl Tomlinson <karlt+@karlt.net> - Tue, 04 Aug 2015 19:42:10 +1200 - rev 257992
bug 962719 remove unnecessary OneIteration() parameters aFrom/aTo r=padenot
d0b0a8015ca0c5fb5df88c14bcd8101d48b1a080: bug 962719 remove notified blocked warning of finished stream r=padenot
Karl Tomlinson <karlt+@karlt.net> - Fri, 31 Jul 2015 22:49:55 +1200 - rev 257991
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.
51ab07894b4937a86e37ac8a8c2a8802b9df48eb: bug 962719 update stream state to processed time after processing r=padenot
Karl Tomlinson <karlt+@karlt.net> - Wed, 29 Jul 2015 19:32:10 +1200 - rev 257990
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.
b5b7c94165f8e2cc618678f12d885abef45c2cea: bug 962719 provide video frames to the container as soon as available r=roc
Karl Tomlinson <karlt+@karlt.net> - Fri, 14 Aug 2015 14:16:57 +1200 - rev 257989
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.
75e8c21a10e6b32da342afddaac184a5cb9f6fd5: bug 1194558 correct time conversion for video frame timestamps r=roc
Karl Tomlinson <karlt+@karlt.net> - Thu, 13 Aug 2015 17:07:49 +1200 - rev 257988
bug 1194558 correct time conversion for video frame timestamps r=roc MediaTimeToSeconds() works fine for negative intervals
e4cadc8dc05885a798be43019e0d9c75b4da572a: bug 962719 provide frame ID service to clients r=roc
Karl Tomlinson <karlt+@karlt.net> - Fri, 07 Aug 2015 11:37:08 +1200 - rev 257987
bug 962719 provide frame ID service to clients r=roc
a4b1ad86a79b17dc18f6b2afa28c06ead84c58e5: bug 962719 make FindChunkContaining() public r=roc
Karl Tomlinson <karlt+@karlt.net> - Tue, 04 Aug 2015 10:42:31 +1200 - rev 257986
bug 962719 make FindChunkContaining() public r=roc
82f1fab387233061a6137c7a104863faa9c294e9: bug 962719 introduce mProcessedTime r=padenot
Karl Tomlinson <karlt+@karlt.net> - Fri, 31 Jul 2015 21:28:29 +1200 - rev 257985
bug 962719 introduce mProcessedTime r=padenot
5eeaba5f8b8a6cb8c7f6e729df1fbf3b13ed7ac1: bug 962719 update NextFrameStatus() on finished notification r=roc
Karl Tomlinson <karlt+@karlt.net> - Tue, 04 Aug 2015 17:43:46 +1200 - rev 257984
bug 962719 update NextFrameStatus() on finished notification r=roc This provides HAVE_CURRENT_DATA readyState.
62d6eeb7619d17ba0ddbcf25ff57f92dd91ec36d: bug 962719 ensure state computed time does not retreat r=padenot
Karl Tomlinson <karlt+@karlt.net> - Tue, 04 Aug 2015 19:54:54 +1200 - rev 257983
bug 962719 ensure state computed time does not retreat r=padenot
f53391f6eea8d5131fe07a2c87df2b9b1d717cfe: bug 962719 remove unnecessary OneIteration() parameter aStateFrom r=padenot
Karl Tomlinson <karlt+@karlt.net> - Fri, 31 Jul 2015 17:39:35 +1200 - rev 257982
bug 962719 remove unnecessary OneIteration() parameter aStateFrom r=padenot
b16ffdc7075f2c04fb3aab1746980c17ba986bc2: bug 962719 move mStateComputedTime to MediaStreamGraphImpl r=padenot
Karl Tomlinson <karlt+@karlt.net> - Thu, 13 Aug 2015 16:23:17 +1200 - rev 257981
bug 962719 move mStateComputedTime to MediaStreamGraphImpl r=padenot
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip