gecko-dev/dom/animation/EffectSet.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

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

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* 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 mozilla_EffectSet_h
#define mozilla_EffectSet_h
#include "mozilla/DebugOnly.h"
#include "mozilla/EffectCompositor.h"
#include "mozilla/EnumeratedArray.h"
#include "mozilla/TimeStamp.h"
#include "mozilla/dom/KeyframeEffect.h"
#include "nsHashKeys.h" // For nsPtrHashKey
#include "nsTHashSet.h"
class nsPresContext;
enum class DisplayItemType : uint8_t;
namespace mozilla {
namespace dom {
class Element;
} // namespace dom
enum class PseudoStyleType : uint8_t;
// A wrapper around a hashset of AnimationEffect objects to handle
// storing the set as a property of an element.
class EffectSet {
public:
EffectSet()
Bug 1228229 part 4 - Add a flag to EffectSet to mark when the cascade needs to be updated; r=dbaron 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. --HG-- extra : rebase_source : fc56b1bb5a98ae78b93a179c7a3b8af4724a06a1
2016-01-06 05:04:04 +03:00
: mCascadeNeedsUpdate(false),
mAnimationGeneration(0)
#ifdef DEBUG
,
mActiveIterators(0),
Bug 1228229 part 4 - Add a flag to EffectSet to mark when the cascade needs to be updated; r=dbaron 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. --HG-- extra : rebase_source : fc56b1bb5a98ae78b93a179c7a3b8af4724a06a1
2016-01-06 05:04:04 +03:00
mCalledPropertyDtor(false)
#endif
,
mMayHaveOpacityAnim(false),
mMayHaveTransformAnim(false) {
MOZ_COUNT_CTOR(EffectSet);
}
~EffectSet() {
MOZ_ASSERT(mCalledPropertyDtor,
"must call destructor through element property dtor");
MOZ_ASSERT(mActiveIterators == 0,
"Effect set should not be destroyed while it is being "
"enumerated");
MOZ_COUNT_DTOR(EffectSet);
}
static void PropertyDtor(void* aObject, nsAtom* aPropertyName,
void* aPropertyValue, void* aData);
// Methods for supporting cycle-collection
void Traverse(nsCycleCollectionTraversalCallback& aCallback);
static EffectSet* GetEffectSet(const dom::Element* aElement,
PseudoStyleType aPseudoType);
static EffectSet* GetOrCreateEffectSet(dom::Element* aElement,
PseudoStyleType aPseudoType);
static EffectSet* GetEffectSetForFrame(const nsIFrame* aFrame,
const nsCSSPropertyIDSet& aProperties);
static EffectSet* GetEffectSetForFrame(const nsIFrame* aFrame,
DisplayItemType aDisplayItemType);
// Gets the EffectSet associated with the specified frame's content.
//
// Typically the specified frame should be a "style frame".
//
// That is because display:table content:
//
// - makes a distinction between the primary frame and style frame,
// - associates the EffectSet with the style frame's content,
// - applies transform animations to the primary frame.
//
// In such a situation, passing in the primary frame here will return nullptr
// despite the fact that it has a transform animation applied to it.
//
// GetEffectSetForFrame, above, handles this by automatically looking up the
// EffectSet on the corresponding style frame when querying transform
// properties. Unless you are sure you know what you are doing, you should
// try using GetEffectSetForFrame first.
//
// If you decide to use this, consider documenting why you are sure it is ok
// to use this.
static EffectSet* GetEffectSetForStyleFrame(const nsIFrame* aStyleFrame);
static EffectSet* GetEffectSetForEffect(const dom::KeyframeEffect* aEffect);
static void DestroyEffectSet(dom::Element* aElement,
PseudoStyleType aPseudoType);
void AddEffect(dom::KeyframeEffect& aEffect);
void RemoveEffect(dom::KeyframeEffect& aEffect);
void SetMayHaveOpacityAnimation() { mMayHaveOpacityAnim = true; }
bool MayHaveOpacityAnimation() const { return mMayHaveOpacityAnim; }
void SetMayHaveTransformAnimation() { mMayHaveTransformAnim = true; }
bool MayHaveTransformAnimation() const { return mMayHaveTransformAnim; }
private:
using OwningEffectSet = nsTHashSet<nsRefPtrHashKey<dom::KeyframeEffect>>;
public:
// A simple iterator to support iterating over the effects in this object in
// range-based for loops.
//
// This allows us to avoid exposing mEffects directly and saves the
// caller from having to dereference hashtable iterators using
// the rather complicated: iter.Get()->GetKey().
//
// XXX Except for the active iterator checks, this could be replaced by the
// STL-style iterators of nsTHashSet directly now.
class Iterator {
public:
explicit Iterator(EffectSet& aEffectSet)
: Iterator(aEffectSet, aEffectSet.mEffects.begin()) {}
Iterator() = delete;
Iterator(const Iterator&) = delete;
Iterator(Iterator&&) = delete;
Iterator& operator=(const Iterator&) = delete;
Iterator& operator=(Iterator&&) = delete;
static Iterator EndIterator(EffectSet& aEffectSet) {
return {aEffectSet, aEffectSet.mEffects.end()};
}
#ifdef DEBUG
~Iterator() {
MOZ_ASSERT(mEffectSet.mActiveIterators > 0);
mEffectSet.mActiveIterators--;
}
#endif
bool operator!=(const Iterator& aOther) const {
return mHashIterator != aOther.mHashIterator;
}
Iterator& operator++() {
++mHashIterator;
return *this;
}
dom::KeyframeEffect* operator*() { return *mHashIterator; }
private:
Iterator(EffectSet& aEffectSet,
OwningEffectSet::const_iterator aHashIterator)
:
#ifdef DEBUG
mEffectSet(aEffectSet),
#endif
mHashIterator(std::move(aHashIterator)) {
#ifdef DEBUG
mEffectSet.mActiveIterators++;
#endif
}
#ifdef DEBUG
EffectSet& mEffectSet;
#endif
OwningEffectSet::const_iterator mHashIterator;
};
friend class Iterator;
Iterator begin() { return Iterator(*this); }
Iterator end() { return Iterator::EndIterator(*this); }
#ifdef DEBUG
bool IsBeingEnumerated() const { return mActiveIterators != 0; }
#endif
bool IsEmpty() const { return mEffects.IsEmpty(); }
size_t Count() const { return mEffects.Count(); }
const TimeStamp& LastOverflowAnimationSyncTime() const {
return mLastOverflowAnimationSyncTime;
}
void UpdateLastOverflowAnimationSyncTime(const TimeStamp& aRefreshTime) {
mLastOverflowAnimationSyncTime = aRefreshTime;
}
Bug 1228229 part 4 - Add a flag to EffectSet to mark when the cascade needs to be updated; r=dbaron 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. --HG-- extra : rebase_source : fc56b1bb5a98ae78b93a179c7a3b8af4724a06a1
2016-01-06 05:04:04 +03:00
bool CascadeNeedsUpdate() const { return mCascadeNeedsUpdate; }
void MarkCascadeNeedsUpdate() { mCascadeNeedsUpdate = true; }
void MarkCascadeUpdated() { mCascadeNeedsUpdate = false; }
void UpdateAnimationGeneration(nsPresContext* aPresContext);
uint64_t GetAnimationGeneration() const { return mAnimationGeneration; }
static nsAtom** GetEffectSetPropertyAtoms();
const nsCSSPropertyIDSet& PropertiesWithImportantRules() const {
return mPropertiesWithImportantRules;
}
nsCSSPropertyIDSet& PropertiesWithImportantRules() {
return mPropertiesWithImportantRules;
}
nsCSSPropertyIDSet& PropertiesForAnimationsLevel() {
return mPropertiesForAnimationsLevel;
}
nsCSSPropertyIDSet PropertiesForAnimationsLevel() const {
return mPropertiesForAnimationsLevel;
}
private:
static nsAtom* GetEffectSetPropertyAtom(PseudoStyleType aPseudoType);
OwningEffectSet mEffects;
// Refresh driver timestamp from the moment when the animations which produce
// overflow change hints in this effect set were last updated.
// This is used for animations whose main-thread restyling is throttled either
// because they are running on the compositor or because they are not visible.
// We still need to update them on the main thread periodically, however (e.g.
// so scrollbars can be updated), so this tracks the last time we did that.
TimeStamp mLastOverflowAnimationSyncTime;
// Dirty flag to represent when the mPropertiesWithImportantRules and
// mPropertiesForAnimationsLevel on effects in this set might need to be
// updated.
Bug 1228229 part 4 - Add a flag to EffectSet to mark when the cascade needs to be updated; r=dbaron 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. --HG-- extra : rebase_source : fc56b1bb5a98ae78b93a179c7a3b8af4724a06a1
2016-01-06 05:04:04 +03:00
//
// Set to true any time the set of effects is changed or when
// one the effects goes in or out of the "in effect" state.
bool mCascadeNeedsUpdate;
// RestyleManager keeps track of the number of animation restyles.
// 'mini-flushes' (see nsTransitionManager::UpdateAllThrottledStyles()).
// mAnimationGeneration is the sequence number of the last flush where a
// transition/animation changed. We keep a similar count on the
// corresponding layer so we can check that the layer is up to date with
// the animation manager.
uint64_t mAnimationGeneration;
// Specifies the compositor-animatable properties that are overridden by
// !important rules.
nsCSSPropertyIDSet mPropertiesWithImportantRules;
// Specifies the properties for which the result will be added to the
// animations level of the cascade and hence should be skipped when we are
// composing the animation style for the transitions level of the cascede.
nsCSSPropertyIDSet mPropertiesForAnimationsLevel;
#ifdef DEBUG
// Track how many iterators are referencing this effect set when we are
// destroyed, we can assert that nothing is still pointing to us.
uint64_t mActiveIterators;
bool mCalledPropertyDtor;
#endif
bool mMayHaveOpacityAnim;
bool mMayHaveTransformAnim;
};
} // namespace mozilla
#endif // mozilla_EffectSet_h