gecko-dev/layout/style/nsAnimationManager.h

360 строки
12 KiB
C
Исходник Обычный вид История

/* vim: set shiftwidth=2 tabstop=8 autoindent cindent expandtab: */
2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef nsAnimationManager_h_
#define nsAnimationManager_h_
#include "mozilla/Attributes.h"
#include "mozilla/ContentEvents.h"
#include "mozilla/EventForwards.h"
#include "AnimationCommon.h"
#include "mozilla/dom/Animation.h"
#include "mozilla/MemoryReporting.h"
#include "mozilla/TimeStamp.h"
class nsIGlobalObject;
class nsStyleContext;
namespace mozilla {
namespace css {
class Declaration;
} /* namespace css */
namespace dom {
class KeyframeEffectReadOnly;
class Promise;
} /* namespace dom */
enum class CSSPseudoElementType : uint8_t;
struct AnimationEventInfo {
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
RefPtr<dom::Element> mElement;
RefPtr<dom::Animation> mAnimation;
InternalAnimationEvent mEvent;
TimeStamp mTimeStamp;
AnimationEventInfo(dom::Element* aElement,
CSSPseudoElementType aPseudoType,
EventMessage aMessage,
const nsSubstring& aAnimationName,
const StickyTimeDuration& aElapsedTime,
const TimeStamp& aTimeStamp,
dom::Animation* aAnimation)
: mElement(aElement)
, mAnimation(aAnimation)
, mEvent(true, aMessage)
, mTimeStamp(aTimeStamp)
{
// XXX Looks like nobody initialize WidgetEvent::time
mEvent.mAnimationName = aAnimationName;
mEvent.mElapsedTime = aElapsedTime.ToSeconds();
mEvent.mPseudoElement =
AnimationCollection<dom::CSSAnimation>::PseudoTypeAsString(aPseudoType);
}
// InternalAnimationEvent doesn't support copy-construction, so we need
// to ourselves in order to work with nsTArray
AnimationEventInfo(const AnimationEventInfo& aOther)
: mElement(aOther.mElement)
, mAnimation(aOther.mAnimation)
, mEvent(true, aOther.mEvent.mMessage)
, mTimeStamp(aOther.mTimeStamp)
{
mEvent.AssignAnimationEventData(aOther.mEvent, false);
}
};
namespace dom {
class CSSAnimation final : public Animation
{
public:
explicit CSSAnimation(nsIGlobalObject* aGlobal,
const nsSubstring& aAnimationName)
: dom::Animation(aGlobal)
, mAnimationName(aAnimationName)
, mIsStylePaused(false)
, mPauseShouldStick(false)
Bug 1203009 part 3 - Add mNeedsNewAnimationIndexWhenRun flag to CSSAnimation and CSSTransition; r=heycam In the new composite order arrangement CSSAnimations and CSSTransition have the following life-cycle: 1. Animation created by markup => composite order determined by markup (e.g. CSS animations use tree order and animation-name order; CSS transitions use transition trigger order) 2. Animation cancelled by changing markup => composite order is undefined 3. Animation is played again using the API => composite order is defined by when the animation is first played. Another way of saying this is that, at the point when the animation is played, it is appended to the "global animation list". 4. Animation is subsequently cancelled / played => no change We need a way to know when we are going from 2 to 3. It would seem like we could do that by setting mAnimationIndex to some sentinel value while it is in 2. However, even when in 2, although the spec doesn't define the composite order animations at this point (from an API point of view you can't access these objects and they don't contribute to style so it doesn't need to be defined), we sometimes will need to establish an order. This can happen, for example, when an animation queues events and then is later cancelled before the events are dispatched. Because we sort events based on their associated animation at the time of dispatch (for performance reasons) we need a deterministic order for these idle animations. We do that (in a subsequent patch in this series) by setting mAnimationIndex when we transition from 1 to 2. That is, these idle animations are effectively ordered by when they became idle (which always happens in a deterministic fashion).
2015-09-15 05:20:33 +03:00
, mNeedsNewAnimationIndexWhenRun(false)
, mPreviousPhase(ComputedTiming::AnimationPhase::Idle)
, mPreviousIteration(0)
{
// We might need to drop this assertion once we add a script-accessible
// constructor but for animations generated from CSS markup the
// animation-name should never be empty.
MOZ_ASSERT(!mAnimationName.IsEmpty(), "animation-name should not be empty");
}
JSObject* WrapObject(JSContext* aCx,
JS::Handle<JSObject*> aGivenProto) override;
CSSAnimation* AsCSSAnimation() override { return this; }
const CSSAnimation* AsCSSAnimation() const override { return this; }
// CSSAnimation interface
void GetAnimationName(nsString& aRetVal) const { aRetVal = mAnimationName; }
// Alternative to GetAnimationName that returns a reference to the member
// for more efficient internal usage.
const nsString& AnimationName() const { return mAnimationName; }
// Animation interface overrides
virtual Promise* GetReady(ErrorResult& aRv) override;
virtual void Play(ErrorResult& aRv, LimitBehavior aLimitBehavior) override;
virtual void Pause(ErrorResult& aRv) override;
virtual AnimationPlayState PlayStateFromJS() const override;
virtual void PlayFromJS(ErrorResult& aRv) override;
void PlayFromStyle();
void PauseFromStyle();
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
void CancelFromStyle() override
{
mOwningElement = OwningElementRef();
// When an animation is disassociated with style it enters an odd state
// where its composite order is undefined until it first transitions
// out of the idle state.
//
// Even if the composite order isn't defined we don't want it to be random
// in case we need to determine the order to dispatch events associated
// with an animation in this state. To solve this we treat the animation as
// if it had been added to the end of the global animation list so that
// its sort order is defined. We'll update this index again once the
// animation leaves the idle state.
mAnimationIndex = sNextAnimationIndex++;
mNeedsNewAnimationIndexWhenRun = true;
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
Animation::CancelFromStyle();
}
void Tick() override;
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.
2015-08-17 07:59:45 +03:00
void QueueEvents();
bool IsStylePaused() const { return mIsStylePaused; }
bool HasLowerCompositeOrderThan(const CSSAnimation& aOther) const;
void SetAnimationIndex(uint64_t aIndex)
{
MOZ_ASSERT(IsTiedToMarkup());
if (IsRelevant() &&
mAnimationIndex != aIndex) {
nsNodeUtils::AnimationChanged(this);
PostUpdate();
}
mAnimationIndex = aIndex;
}
// Sets the owning element which is used for determining the composite
// order of CSSAnimation objects generated from CSS markup.
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
//
// @see mOwningElement
void SetOwningElement(const OwningElementRef& aElement)
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
{
mOwningElement = aElement;
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
}
// True for animations that are generated from CSS markup and continue to
// reflect changes to that markup.
bool IsTiedToMarkup() const { return mOwningElement.IsSet(); }
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
protected:
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
virtual ~CSSAnimation()
{
MOZ_ASSERT(!mOwningElement.IsSet(), "Owning element should be cleared "
"before a CSS animation is destroyed");
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
}
// Animation overrides
void UpdateTiming(SeekFlag aSeekFlag,
SyncNotifyFlag aSyncNotifyFlag) override;
// Returns the duration from the start of the animation's source effect's
// active interval to the point where the animation actually begins playback.
// This is zero unless the animation's source effect has a negative delay in
// which case it is the absolute value of that delay.
// This is used for setting the elapsedTime member of CSS AnimationEvents.
TimeDuration InitialAdvance() const {
return mEffect ?
std::max(TimeDuration(), mEffect->SpecifiedTiming().mDelay * -1) :
TimeDuration();
}
nsString mAnimationName;
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
// The (pseudo-)element whose computed animation-name refers to this
// animation (if any).
//
// This is used for determining the relative composite order of animations
// generated from CSS markup.
//
// Typically this will be the same as the target element of the keyframe
// effect associated with this animation. However, it can differ in the
// following circumstances:
//
// a) If script removes or replaces the effect of this animation,
// b) If this animation is cancelled (e.g. by updating the
// animation-name property or removing the owning element from the
// document),
// c) If this object is generated from script using the CSSAnimation
// constructor.
//
// For (b) and (c) the owning element will return !IsSet().
OwningElementRef mOwningElement;
Bug 1171817 part 2 - Add CSSAnimation::GetOwningElement; r=dbaron In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removes the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This scenario does not yet occur (bug 1049975). 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Until we implement bug 1049975, we could support sorting animations without adding the reference to the owning element by setting a flag on the CSSAnimation object but (having tried this) it turns out to be cleaner to just introduce this reference now, particularly since we know we will need it later. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values. --HG-- extra : commitid : 8o9bf6l7kj7 extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
2015-06-09 05:13:53 +03:00
// When combining animation-play-state with play() / pause() the following
// behavior applies:
// 1. pause() is sticky and always overrides the underlying
// animation-play-state
// 2. If animation-play-state is 'paused', play() will temporarily override
// it until animation-play-state next becomes 'running'.
// 3. Calls to play() trigger finishing behavior but setting the
// animation-play-state to 'running' does not.
//
// This leads to five distinct states:
//
// A. Running
// B. Running and temporarily overriding animation-play-state: paused
// C. Paused and sticky overriding animation-play-state: running
// D. Paused and sticky overriding animation-play-state: paused
// E. Paused by animation-play-state
//
// C and D may seem redundant but they differ in how to respond to the
// sequence: call play(), set animation-play-state: paused.
//
// C will transition to A then E leaving the animation paused.
// D will transition to B then B leaving the animation running.
//
// A state transition chart is as follows:
//
// A | B | C | D | E
// ---------------------------
// play() A | B | A | B | B
// pause() C | D | C | D | D
// 'running' A | A | C | C | A
// 'paused' E | B | D | D | E
//
// The base class, Animation already provides a boolean value,
// mIsPaused which gives us two states. To this we add a further two booleans
// to represent the states as follows.
//
// A. Running
// (!mIsPaused; !mIsStylePaused; !mPauseShouldStick)
// B. Running and temporarily overriding animation-play-state: paused
// (!mIsPaused; mIsStylePaused; !mPauseShouldStick)
// C. Paused and sticky overriding animation-play-state: running
// (mIsPaused; !mIsStylePaused; mPauseShouldStick)
// D. Paused and sticky overriding animation-play-state: paused
// (mIsPaused; mIsStylePaused; mPauseShouldStick)
// E. Paused by animation-play-state
// (mIsPaused; mIsStylePaused; !mPauseShouldStick)
//
// (That leaves 3 combinations of the boolean values that we never set because
// they don't represent valid states.)
bool mIsStylePaused;
bool mPauseShouldStick;
Bug 1203009 part 3 - Add mNeedsNewAnimationIndexWhenRun flag to CSSAnimation and CSSTransition; r=heycam In the new composite order arrangement CSSAnimations and CSSTransition have the following life-cycle: 1. Animation created by markup => composite order determined by markup (e.g. CSS animations use tree order and animation-name order; CSS transitions use transition trigger order) 2. Animation cancelled by changing markup => composite order is undefined 3. Animation is played again using the API => composite order is defined by when the animation is first played. Another way of saying this is that, at the point when the animation is played, it is appended to the "global animation list". 4. Animation is subsequently cancelled / played => no change We need a way to know when we are going from 2 to 3. It would seem like we could do that by setting mAnimationIndex to some sentinel value while it is in 2. However, even when in 2, although the spec doesn't define the composite order animations at this point (from an API point of view you can't access these objects and they don't contribute to style so it doesn't need to be defined), we sometimes will need to establish an order. This can happen, for example, when an animation queues events and then is later cancelled before the events are dispatched. Because we sort events based on their associated animation at the time of dispatch (for performance reasons) we need a deterministic order for these idle animations. We do that (in a subsequent patch in this series) by setting mAnimationIndex when we transition from 1 to 2. That is, these idle animations are effectively ordered by when they became idle (which always happens in a deterministic fashion).
2015-09-15 05:20:33 +03:00
// When true, indicates that when this animation next leaves the idle state,
// its animation index should be updated.
bool mNeedsNewAnimationIndexWhenRun;
// Phase and current iteration from the previous time we queued events.
// This is used to determine what new events to dispatch.
ComputedTiming::AnimationPhase mPreviousPhase;
uint64_t mPreviousIteration;
};
} /* namespace dom */
template <>
struct AnimationTypeTraits<dom::CSSAnimation>
{
static nsIAtom* ElementPropertyAtom()
{
return nsGkAtoms::animationsProperty;
}
static nsIAtom* BeforePropertyAtom()
{
return nsGkAtoms::animationsOfBeforeProperty;
}
static nsIAtom* AfterPropertyAtom()
{
return nsGkAtoms::animationsOfAfterProperty;
}
};
} /* namespace mozilla */
class nsAnimationManager final
: public mozilla::CommonAnimationManager<mozilla::dom::CSSAnimation>
{
public:
explicit nsAnimationManager(nsPresContext *aPresContext)
: mozilla::CommonAnimationManager<mozilla::dom::CSSAnimation>(aPresContext)
{
}
NS_INLINE_DECL_CYCLE_COLLECTING_NATIVE_REFCOUNTING(nsAnimationManager)
NS_DECL_CYCLE_COLLECTION_NATIVE_CLASS(nsAnimationManager)
typedef mozilla::AnimationCollection<mozilla::dom::CSSAnimation>
CSSAnimationCollection;
typedef nsTArray<RefPtr<mozilla::dom::CSSAnimation>>
OwningCSSAnimationPtrArray;
/**
* Update the set of animations on |aElement| based on |aStyleContext|.
* If necessary, this will notify the corresponding EffectCompositor so
* that it can update its animation rule.
*
* aStyleContext may be a style context for aElement or for its
* :before or :after pseudo-element.
*/
void UpdateAnimations(nsStyleContext* aStyleContext,
mozilla::dom::Element* aElement);
/**
* Add a pending event.
*/
void QueueEvent(mozilla::AnimationEventInfo&& aEventInfo)
{
mEventDispatcher.QueueEvent(
mozilla::Forward<mozilla::AnimationEventInfo>(aEventInfo));
}
/**
* Dispatch any pending events. We accumulate animationend and
* animationiteration events only during refresh driver notifications
* (and dispatch them at the end of such notifications), but we
* accumulate animationstart events at other points when style
* contexts are created.
*/
2016-02-10 16:17:05 +03:00
void DispatchEvents()
{
RefPtr<nsAnimationManager> kungFuDeathGrip(this);
mEventDispatcher.DispatchEvents(mPresContext);
}
void SortEvents() { mEventDispatcher.SortEvents(); }
void ClearEventQueue() { mEventDispatcher.ClearEventQueue(); }
// Stop animations on the element. This method takes the real element
// rather than the element for the generated content for animations on
// ::before and ::after.
void StopAnimationsForElement(mozilla::dom::Element* aElement,
mozilla::CSSPseudoElementType aPseudoType);
protected:
~nsAnimationManager() override = default;
private:
void BuildAnimations(nsStyleContext* aStyleContext,
mozilla::dom::Element* aTarget,
CSSAnimationCollection* aCollection,
OwningCSSAnimationPtrArray& aAnimations);
mozilla::DelayedEventDispatcher<mozilla::AnimationEventInfo> mEventDispatcher;
};
#endif /* !defined(nsAnimationManager_h_) */