The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
This corresponds to the approach outlined in https://github.com/w3c/csswg-drafts/issues/4822
Specifically:
* Calling play() / pause() always triggers the "animation play state is being
overridden by the API" behavior (unless the method throws an exception).
* Setting the startTime or calling reverse() only triggers this override
behavior if it results in a change between a playState that is paused and a
playState that is not paused.
Differential Revision: https://phabricator.services.mozilla.com/D65100
--HG--
extra : moz-landing-system : lando
We only support writable Animation.timeline attribute on nightly
build, so use nightly build flag in WebIDL and Animation.h/cpp.
For the test expectations, we also use this build flag to skip them or
mark them as expected fail if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D63432
--HG--
extra : moz-landing-system : lando
Replace ElementOrCSSPseudoElement with Element and add PseudoElement (which is
a DOMString) into KeyframeAnimationOptions and KeyframeEffect.
Differential Revision: https://phabricator.services.mozilla.com/D62667
--HG--
extra : moz-landing-system : lando
The in-class initializers are easier to maintain since you don't have to try and
match them up with the constructor initializer list (including matching the
order).
Differential Revision: https://phabricator.services.mozilla.com/D30317
--HG--
extra : moz-landing-system : lando
Currently we avoid posting animation restyles when unbinding an element by
removing the element from the document before deleting its animation
collections. As a result, when canceled animations go to post a restyle, they
can't find a pres context and give up posting a restyle.
However, this is problematic for two reasons:
* It means we can't remove such canceled animations from the
PendingAnimationTracker if they are present there (i.e. it regresses the fix
from bug 1223445).
* It means we can't post cancel events for such animations/transitions since we
can't lookup the appropriate AnimationEventDispatcher.
In the next patch in this series we will change that order to fix the above
problems but before we do that, we need to introduce another mechanism to make
sure that we don't post restyles when unbinding an element or else we will
regress bug 1396041.
This patch does that by introducing a flag which causes us to not post restyles
when we are doing DOM surgery. For all other cases we actually _do_ need to post
restyles in order to update the style correctly.
Without this patch, layout/style/crashtests/1396041.html would fail after
applying the next patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D28021
--HG--
extra : moz-landing-system : lando
CancelNoUpdate actually can and does trigger restyles via its call to
KeyframeEffect::NotifyAnimationTimingUpdated so at very least its name is wrong.
Furthermore, we actually want canceling to trigger restyles in most cases since
when an animation is canceled we need to trigger a subsequent restyle to apply
the (no-longer-animated) result.
This wasn't necessary when CancelNoUpdate was first introduced but since then we
have introduced the Servo style engine where we use a separate traversal to
apply the result from creating/deleting/modifying animations.
This change will mean that we now trigger a "layer" restyle when canceling an
animation when we previously didn't. That, however, seems more correct if
anything.
This patch also makes CancelFromStyle no longer virtual since it doesn't seem
necessary anymore (perhaps because we now point to the concrete type:
CSSAnimation/CSSTransition from nsAnimationManager/nsTransitionManager whereas
previously we didn't).
Differential Revision: https://phabricator.services.mozilla.com/D28019
--HG--
extra : moz-landing-system : lando
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
--HG--
extra : moz-landing-system : lando
As of bug 1203009 / changeset 37b6deedaab6 and per spec, we no longer reset the
animation index when an Animation re-enters the idle state and kNoIndex is no
longer defined.
Depends on D15898
Differential Revision: https://phabricator.services.mozilla.com/D15899
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
So that we can use for KeyframeEffect::GetPropertiesForCompositor().
Depends on D12396
Differential Revision: https://phabricator.services.mozilla.com/D12397
--HG--
extra : moz-landing-system : lando
The function will be used in the case of KeyframeEffect::SetTarget too.
MozReview-Commit-ID: G6ipjxaIJsW
--HG--
extra : rebase_source : 609fa17d698612df21d9cac469e6997582dcca69
Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
--HG--
extra : rebase_source : 3c68ef330b1f263afa2fad9670a30b351b8dbf28
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Animation::FlushStyle() gets called only for CSS animations/transitions'
playState changes in JS or ready Promise for CSS animations. In either case
throttled animation state, which is, to be precise, transformed position or
opacity value on the compositor, doesn't affect those results.
The first test case for CSS animations and the first test case for CSS
transitions in this patch fail without this fix.
MozReview-Commit-ID: EVym4qputL4
--HG--
extra : rebase_source : 12524c7db1d59da69687bb123fc65ad4301f5527
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
We will use this to calculate the unconstrained current time when we implement
pending playback rate changes.
MozReview-Commit-ID: 7GlmHiGeXF6
--HG--
extra : rebase_source : 32c0c4d86293bf11220017fa1b126ae239b0301d
We will re-use these methods to perform various calculations once we introduce
the pending playback rate.
MozReview-Commit-ID: 2HV44TTNxHg
--HG--
extra : rebase_source : 19e32b13c6fee9cfe9993918557f2433aa687e11
This is the IDL added to the Web Animations specification:
5af5e276ba
Note that some of the changes in the above commit were reverted in the following
commit:
673f6fc126
A folded version of the changes:
https://gist.github.com/birtles/d147eb2e0e2d4d37fadf217abd709411
MozReview-Commit-ID: CJV7bzizXg4
--HG--
extra : rebase_source : 3b168e779883ba91c8f572478185b55013952d1a
Hiroyuki Ikezoe
Brindusan Cristian
Emily McDonough
Brian Birtles
Boris Chiou
Simon Giesecke
Mirko Brodesser
Ehsan Akhgari
Emilio Cobos Álvarez
Sylvestre Ledru
Hiroyuki Ikezoe
Olli Pettay
Chris Peterson
Csoregi Natalia
arthur.iakab