gecko-dev/layout/style/AnimationCommon.cpp

723 строки
21 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/. */
#include "AnimationCommon.h"
#include "nsTransitionManager.h"
#include "nsAnimationManager.h"
#include "ActiveLayerTracker.h"
#include "gfxPlatform.h"
#include "nsRuleData.h"
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
#include "nsCSSPropertySet.h"
#include "nsCSSValue.h"
#include "nsCycleCollectionParticipant.h"
#include "nsDOMMutationObserver.h"
#include "nsStyleContext.h"
#include "nsIFrame.h"
#include "nsLayoutUtils.h"
#include "LayerAnimationInfo.h" // For LayerAnimationInfo::sRecords
#include "FrameLayerBuilder.h"
#include "nsDisplayList.h"
#include "mozilla/MemoryReporting.h"
#include "mozilla/dom/KeyframeEffect.h"
#include "RestyleManager.h"
#include "nsRuleProcessorData.h"
#include "nsStyleSet.h"
#include "nsStyleChangeList.h"
using mozilla::dom::Animation;
using mozilla::dom::KeyframeEffectReadOnly;
namespace mozilla {
CommonAnimationManager::CommonAnimationManager(nsPresContext *aPresContext)
: mPresContext(aPresContext)
{
}
CommonAnimationManager::~CommonAnimationManager()
{
MOZ_ASSERT(!mPresContext, "Disconnect should have been called");
}
void
CommonAnimationManager::Disconnect()
{
// Content nodes might outlive the transition or animation manager.
RemoveAllElementCollections();
mPresContext = nullptr;
}
void
CommonAnimationManager::AddElementCollection(AnimationCollection* aCollection)
{
mElementCollections.insertBack(aCollection);
}
void
CommonAnimationManager::RemoveAllElementCollections()
{
while (AnimationCollection* head = mElementCollections.getFirst()) {
head->Destroy(); // Note: this removes 'head' from mElementCollections.
}
}
AnimationCollection*
CommonAnimationManager::GetAnimationCollection(const nsIFrame* aFrame)
{
nsIContent* content = aFrame->GetContent();
if (!content) {
return nullptr;
}
nsIAtom* animProp;
if (aFrame->IsGeneratedContentFrame()) {
nsIFrame* parent = aFrame->GetParent();
if (parent->IsGeneratedContentFrame()) {
return nullptr;
}
nsIAtom* name = content->NodeInfo()->NameAtom();
if (name == nsGkAtoms::mozgeneratedcontentbefore) {
animProp = GetAnimationsBeforeAtom();
} else if (name == nsGkAtoms::mozgeneratedcontentafter) {
animProp = GetAnimationsAfterAtom();
} else {
return nullptr;
}
content = content->GetParent();
if (!content) {
return nullptr;
}
} else {
if (!content->MayHaveAnimations()) {
return nullptr;
}
animProp = GetAnimationsAtom();
}
return static_cast<AnimationCollection*>(content->GetProperty(animProp));
}
AnimationCollection*
CommonAnimationManager::GetAnimationsForCompositor(const nsIFrame* aFrame,
nsCSSProperty aProperty)
{
AnimationCollection* collection = GetAnimationCollection(aFrame);
if (!collection ||
Bug 1181392 part 5 - Remove use of IsFinishedTransition from AnimationCollection::HasAnimationOfProperty; r=dbaron AnimationCollection::HasAnimationOfProperty uses IsFinishedTransition to filter out transitions that should otherwise be ignored. This is used in the following places: 1. nsLayoutUtils::HasAnimations The is only used by nsIFrame::BuildDisplayListForStackingContext to see if there are any opacity animations For this case, simply returning *current* animations would be sufficient (since finished but filling animations should have already filled in the display opacity) 2. CommonAnimationManager::GetAnimationsForCompositor This should really only return *current* animations--that is, animations that are running or scheduled to run. Finished animations never run on the compositor. Indeed, only *playing* animations run on the compositor but, as we will see in some of the cases below, it is sometimes useful to know that an animation *will* run on the compositor in the near future (e.g. so we can pre-render content). The places where GetAnimationsForCompositor is used are: - When building layers to add animations to layers in nsDisplayList--in this case we skip any animations that aren't playing so if GetAnimationsForCompositor only returned current animations that would be more than sufficient. - In nsLayoutUtils::HasAnimationsForCompositor. This in turn is used: - In ChooseScaleAndSetTransform to see if the transform is being animated on the compositor. If so, it calls nsLayoutUtils::ComputeSuitableScaleForAnimation (which also calls GetAnimationsForCompositor) and passes the result to GetMinAndMaxScaleForAnimationProperty which we have already adjusted in part 4 of this patch series to only deal with *relevant* animations Relevant animations include both current animations and in effect animations but we don't run forwards-filling animations on the compositor so GetAnimationsForCompositor should NOT return them. Current animations should be enough. In fact, playing animations should be enough but we might want to pre-render layers at a suitable size during their delay phase so returning current animations is probably ok. - In nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay to add a fuzz factor to the overflow rect for frames undergoing a transform animation on the compositor. In this case too current animations should be sufficient. - In nsDisplayOpacity::NeedsActiveLayer to say "yes" if we are animating opacity on the compositor. Presumably in this case it would be good to say "yes" if the animation is in the delay phase too (as it currently does). After the animation is finished, we should drop the layer, i.e. current animations should be sufficient. - In nsDisplayTransform::ShouldPrerenderTransformedContent. As with nsDisplayOpacity::NeedsActiveLayer, we only need to pre-render transformed content for animations that are current. - In nsDisplayTransform::GetLayerState. As with nsDisplayOpacity::NeedsActiveLayer, we only need to return active here for current animations. - In nsIFrame::IsTransformed. Here we test the display style to see if there is a transform and also check if transform is being animated on the compositor. As a result, we really only need HasAnimationsForCompositor to return true for animations that are playing--otherwise the display style will tell us if we're transformed or not. Returning true for all current compositor animations (which is a superset of playing), however, should not cause problems (we already return true for even more than that). - In nsIFrame::HasOpacityInternal which is much the same as nsIFrame::IsTransformed and hence current should be fine. 3. AnimationCollection::CanThrottleAnimation Here, HasAnimationOfProperty is used when looking for animations that would disqualify us from throttling the animation by having an out-of-date layer generation or being a transform animation that affects scroll and so requires that we do the occasional main thread sample to update scrollbars. It would seem like current animations are enough here too. One interesting case is where we *had* a compositor animation but it has finished or been cancelled. In that case, the animation won't be current and we should not throttle the animation since we need to take it off its layer. It turns out checking for current animations is still ok in this case too. The reasoning is as follows: - If the animation is newly-finished, we'll pick that up in Animation::CanThrottle and return false then. - If the animation is newly-idle then there are two cases: If the cancelled animation was the only compositor animation then AnimationCollection::CanPerformOnCompositorThread will notice that there are no playing compositor animations and return false and AnimationCollection::CanThrottleAnimation will never be called. If there are other compositor animations running, then AnimationCollection::CanThrottleAnimation will still return false because whatever cancelled the animation will update the animation generation and we'll notice the mismatch between the layer animation generation and the animation generation on the collection. Based on the above analysis it appears that making AnimationCollection::HasAnimationOfProperty return only current animations (and simulatneously renaming it to HasCurrentAnimationOfProperty) is safe. Indeed, in effect, we already do this for transitions but not for animations. This patch generalizes this behavior to all animations. This patch also updates test_animations_omta.html since it was incorrectly testing that a finished opacity animation was still running on the compositor. Finished animations should not run on the compositor and the changes in this patch cause that to happen. The reason we don't just update this test to check for RunningOn.MainThread is that for opacity animations, unlike transform animations, we can't detect if an opacity on a layer was set by animation or not. As a result, for opacity animations we typically test the opacity on either the main thread or compositor in order to allow for the case where an animation-set opacity is still lingering on the compositor.
2015-08-07 06:29:36 +03:00
!collection->HasCurrentAnimationOfProperty(aProperty) ||
!collection->CanPerformOnCompositorThread(aFrame)) {
return nullptr;
}
// This animation can be done on the compositor.
return collection;
}
nsRestyleHint
CommonAnimationManager::HasStateDependentStyle(StateRuleProcessorData* aData)
{
return nsRestyleHint(0);
}
nsRestyleHint
CommonAnimationManager::HasStateDependentStyle(PseudoElementStateRuleProcessorData* aData)
{
return nsRestyleHint(0);
}
bool
CommonAnimationManager::HasDocumentStateDependentStyle(StateRuleProcessorData* aData)
{
return false;
}
nsRestyleHint
CommonAnimationManager::HasAttributeDependentStyle(
AttributeRuleProcessorData* aData,
RestyleHintData& aRestyleHintDataResult)
{
return nsRestyleHint(0);
}
/* virtual */ bool
CommonAnimationManager::MediumFeaturesChanged(nsPresContext* aPresContext)
{
return false;
}
/* virtual */ void
CommonAnimationManager::RulesMatching(ElementRuleProcessorData* aData)
{
MOZ_ASSERT(aData->mPresContext == mPresContext,
"pres context mismatch");
nsIStyleRule *rule =
GetAnimationRule(aData->mElement,
nsCSSPseudoElements::ePseudo_NotPseudoElement);
if (rule) {
aData->mRuleWalker->Forward(rule);
aData->mRuleWalker->CurrentNode()->SetIsAnimationRule();
}
}
/* virtual */ void
CommonAnimationManager::RulesMatching(PseudoElementRuleProcessorData* aData)
{
MOZ_ASSERT(aData->mPresContext == mPresContext,
"pres context mismatch");
if (aData->mPseudoType != nsCSSPseudoElements::ePseudo_before &&
aData->mPseudoType != nsCSSPseudoElements::ePseudo_after) {
return;
}
// FIXME: Do we really want to be the only thing keeping a
// pseudo-element alive? I *think* the non-animation restyle should
// handle that, but should add a test.
nsIStyleRule *rule = GetAnimationRule(aData->mElement, aData->mPseudoType);
if (rule) {
aData->mRuleWalker->Forward(rule);
aData->mRuleWalker->CurrentNode()->SetIsAnimationRule();
}
}
/* virtual */ void
CommonAnimationManager::RulesMatching(AnonBoxRuleProcessorData* aData)
{
}
#ifdef MOZ_XUL
/* virtual */ void
CommonAnimationManager::RulesMatching(XULTreeRuleProcessorData* aData)
{
}
#endif
/* virtual */ size_t
CommonAnimationManager::SizeOfExcludingThis(mozilla::MallocSizeOf aMallocSizeOf) const
{
// Measurement of the following members may be added later if DMD finds it is
// worthwhile:
// - mElementCollections
//
// The following members are not measured
// - mPresContext, because it's non-owning
return 0;
}
/* virtual */ size_t
CommonAnimationManager::SizeOfIncludingThis(mozilla::MallocSizeOf aMallocSizeOf) const
{
return aMallocSizeOf(this) + SizeOfExcludingThis(aMallocSizeOf);
}
void
CommonAnimationManager::AddStyleUpdatesTo(RestyleTracker& aTracker)
{
TimeStamp now = mPresContext->RefreshDriver()->MostRecentRefresh();
for (AnimationCollection* collection = mElementCollections.getFirst();
collection; collection = collection->getNext()) {
Bug 1188251 part 10 - Remove throttling from EnsureStyleRuleFor; r=dholbert EnsureStyleRuleFor contains logic for performing throttled updates to the style rule but it is only used in one case: inside nsTransitionManager::UpdateCascadeResults to determine what properties are being animated by CSS animations. We would like to remove throttling logic from EnsureStyleRuleFor altogether but if that one case where it is currently used is run on every tick then removing this logic could effectively mean we end up updating the style rule on every tick. Fortunately nsTransitionManager::UpdateCascadeResults is only called in the following cases: 1. From nsTransitionManager::StyleContextChanged (via TransitionManager::UpdateCascadeResultsWithTransitions), when we are processing style changes for transitions. 2. From AnimationCollection::EnsureStyleRuleFor (via nsAnimationManager::MaybeUpdateCascadeResults and nsTransitionManager::UpdateCascadeResultsWithAnimations), when we are updating the animation style rule from CSS animations. 3. From nsAnimationManager::CheckAnimationRule (via TransitionManager::UpdateCascadeResultsWithAnimationsToBeDestroyed), when we are processing style changes for CSS animations. None of these things should be happenning on a regular throttle-able tick so by removing this logic we shouldn't be causing any additional work. I have verified, using a test case that combines transitions and animations on the same property, that we have the same behavior with regard to calling EnsureStyleRuleFor both before and after this patch (specifically we avoid calling it altogether while running only the transition but when the animation starts and clobbers the transition we end up calling EnsureStyleRuleFor once on each tick).
2015-08-18 10:11:55 +03:00
collection->EnsureStyleRuleFor(now);
dom::Element* elementToRestyle = collection->GetElementToRestyle();
if (elementToRestyle) {
nsRestyleHint rshint = collection->IsForTransitions()
? eRestyle_CSSTransitions : eRestyle_CSSAnimations;
aTracker.AddPendingRestyle(elementToRestyle, rshint, nsChangeHint(0));
}
}
}
/* static */ bool
CommonAnimationManager::ExtractComputedValueForTransition(
nsCSSProperty aProperty,
nsStyleContext* aStyleContext,
StyleAnimationValue& aComputedValue)
{
bool result = StyleAnimationValue::ExtractComputedValue(aProperty,
aStyleContext,
aComputedValue);
if (aProperty == eCSSProperty_visibility) {
MOZ_ASSERT(aComputedValue.GetUnit() ==
StyleAnimationValue::eUnit_Enumerated,
"unexpected unit");
aComputedValue.SetIntValue(aComputedValue.GetIntValue(),
StyleAnimationValue::eUnit_Visibility);
}
return result;
}
AnimationCollection*
CommonAnimationManager::GetAnimations(dom::Element *aElement,
nsCSSPseudoElements::Type aPseudoType,
bool aCreateIfNeeded)
{
if (!aCreateIfNeeded && mElementCollections.isEmpty()) {
// Early return for the most common case.
return nullptr;
}
nsIAtom *propName;
if (aPseudoType == nsCSSPseudoElements::ePseudo_NotPseudoElement) {
propName = GetAnimationsAtom();
} else if (aPseudoType == nsCSSPseudoElements::ePseudo_before) {
propName = GetAnimationsBeforeAtom();
} else if (aPseudoType == nsCSSPseudoElements::ePseudo_after) {
propName = GetAnimationsAfterAtom();
} else {
NS_ASSERTION(!aCreateIfNeeded,
"should never try to create transitions for pseudo "
"other than :before or :after");
return nullptr;
}
AnimationCollection* collection =
static_cast<AnimationCollection*>(aElement->GetProperty(propName));
if (!collection && aCreateIfNeeded) {
// FIXME: Consider arena-allocating?
collection = new AnimationCollection(aElement, propName, this);
nsresult rv =
aElement->SetProperty(propName, collection,
&AnimationCollection::PropertyDtor, false);
if (NS_FAILED(rv)) {
NS_WARNING("SetProperty failed");
// The collection must be destroyed via PropertyDtor, otherwise
// mCalledPropertyDtor assertion is triggered in destructor.
AnimationCollection::PropertyDtor(aElement, propName, collection, nullptr);
return nullptr;
}
if (aPseudoType == nsCSSPseudoElements::ePseudo_NotPseudoElement) {
aElement->SetMayHaveAnimations();
}
AddElementCollection(collection);
}
return collection;
}
void
CommonAnimationManager::FlushAnimations()
{
TimeStamp now = mPresContext->RefreshDriver()->MostRecentRefresh();
for (AnimationCollection* collection = mElementCollections.getFirst();
collection; collection = collection->getNext()) {
if (collection->mStyleRuleRefreshTime == now) {
continue;
}
MOZ_ASSERT(collection->mElement->GetComposedDoc() ==
mPresContext->Document(),
"Should not have a transition/animation collection for an "
"element that is not part of the document tree");
collection->RequestRestyle(AnimationCollection::RestyleType::Standard);
}
}
nsIStyleRule*
CommonAnimationManager::GetAnimationRule(mozilla::dom::Element* aElement,
nsCSSPseudoElements::Type aPseudoType)
{
MOZ_ASSERT(
aPseudoType == nsCSSPseudoElements::ePseudo_NotPseudoElement ||
aPseudoType == nsCSSPseudoElements::ePseudo_before ||
aPseudoType == nsCSSPseudoElements::ePseudo_after,
"forbidden pseudo type");
if (!mPresContext->IsDynamic()) {
// For print or print preview, ignore animations.
return nullptr;
}
AnimationCollection* collection =
GetAnimations(aElement, aPseudoType, false);
if (!collection) {
return nullptr;
}
RestyleManager* restyleManager = mPresContext->RestyleManager();
if (restyleManager->SkipAnimationRules()) {
return nullptr;
}
collection->EnsureStyleRuleFor(
Bug 1188251 part 10 - Remove throttling from EnsureStyleRuleFor; r=dholbert EnsureStyleRuleFor contains logic for performing throttled updates to the style rule but it is only used in one case: inside nsTransitionManager::UpdateCascadeResults to determine what properties are being animated by CSS animations. We would like to remove throttling logic from EnsureStyleRuleFor altogether but if that one case where it is currently used is run on every tick then removing this logic could effectively mean we end up updating the style rule on every tick. Fortunately nsTransitionManager::UpdateCascadeResults is only called in the following cases: 1. From nsTransitionManager::StyleContextChanged (via TransitionManager::UpdateCascadeResultsWithTransitions), when we are processing style changes for transitions. 2. From AnimationCollection::EnsureStyleRuleFor (via nsAnimationManager::MaybeUpdateCascadeResults and nsTransitionManager::UpdateCascadeResultsWithAnimations), when we are updating the animation style rule from CSS animations. 3. From nsAnimationManager::CheckAnimationRule (via TransitionManager::UpdateCascadeResultsWithAnimationsToBeDestroyed), when we are processing style changes for CSS animations. None of these things should be happenning on a regular throttle-able tick so by removing this logic we shouldn't be causing any additional work. I have verified, using a test case that combines transitions and animations on the same property, that we have the same behavior with regard to calling EnsureStyleRuleFor both before and after this patch (specifically we avoid calling it altogether while running only the transition but when the animation starts and clobbers the transition we end up calling EnsureStyleRuleFor once on each tick).
2015-08-18 10:11:55 +03:00
mPresContext->RefreshDriver()->MostRecentRefresh());
return collection->mStyleRule;
}
void
CommonAnimationManager::ClearIsRunningOnCompositor(const nsIFrame* aFrame,
nsCSSProperty aProperty)
{
AnimationCollection* collection = GetAnimationCollection(aFrame);
if (collection) {
collection->ClearIsRunningOnCompositor(aProperty);
}
}
NS_IMPL_ISUPPORTS(AnimValuesStyleRule, nsIStyleRule)
/* virtual */ void
AnimValuesStyleRule::MapRuleInfoInto(nsRuleData* aRuleData)
{
nsStyleContext *contextParent = aRuleData->mStyleContext->GetParent();
if (contextParent && contextParent->HasPseudoElementData()) {
// Don't apply transitions or animations to things inside of
// pseudo-elements.
// FIXME (Bug 522599): Add tests for this.
// Prevent structs from being cached on the rule node since we're inside
// a pseudo-element, as we could determine cacheability differently
// when walking the rule tree for a style context that is not inside
// a pseudo-element. Note that nsRuleNode::GetStyle##name_ and GetStyleData
// will never look at cached structs when we're animating things inside
// a pseduo-element, so that we don't incorrectly return a struct that
// is only appropriate for non-pseudo-elements.
aRuleData->mConditions.SetUncacheable();
return;
}
for (uint32_t i = 0, i_end = mPropertyValuePairs.Length(); i < i_end; ++i) {
PropertyValuePair &cv = mPropertyValuePairs[i];
if (aRuleData->mSIDs & nsCachedStyleData::GetBitForSID(
nsCSSProps::kSIDTable[cv.mProperty]))
{
nsCSSValue *prop = aRuleData->ValueFor(cv.mProperty);
if (prop->GetUnit() == eCSSUnit_Null) {
#ifdef DEBUG
bool ok =
#endif
StyleAnimationValue::UncomputeValue(cv.mProperty, cv.mValue, *prop);
MOZ_ASSERT(ok, "could not store computed value");
}
}
}
}
#ifdef DEBUG
/* virtual */ void
AnimValuesStyleRule::List(FILE* out, int32_t aIndent) const
{
nsAutoCString str;
for (int32_t index = aIndent; --index >= 0; ) {
str.AppendLiteral(" ");
}
str.AppendLiteral("[anim values] { ");
for (uint32_t i = 0, i_end = mPropertyValuePairs.Length(); i < i_end; ++i) {
const PropertyValuePair &pair = mPropertyValuePairs[i];
str.Append(nsCSSProps::GetStringValue(pair.mProperty));
str.AppendLiteral(": ");
nsAutoString value;
StyleAnimationValue::UncomputeValue(pair.mProperty, pair.mValue, value);
AppendUTF16toUTF8(value, str);
str.AppendLiteral("; ");
}
str.AppendLiteral("}\n");
fprintf_stderr(out, "%s", str.get());
}
#endif
bool
AnimationCollection::CanPerformOnCompositorThread(const nsIFrame* aFrame) const
{
if (!nsLayoutUtils::AreAsyncAnimationsEnabled()) {
if (nsLayoutUtils::IsAnimationLoggingEnabled()) {
nsCString message;
message.AppendLiteral("Performance warning: Async animations are disabled");
LogAsyncAnimationFailure(message);
}
return false;
}
if (aFrame->RefusedAsyncAnimation()) {
return false;
}
for (size_t animIdx = mAnimations.Length(); animIdx-- != 0; ) {
const Animation* anim = mAnimations[animIdx];
if (!anim->IsPlaying()) {
continue;
}
const KeyframeEffectReadOnly* effect = anim->GetEffect();
MOZ_ASSERT(effect, "A playing animation should have an effect");
for (size_t propIdx = 0, propEnd = effect->Properties().Length();
propIdx != propEnd; ++propIdx) {
const AnimationProperty& prop = effect->Properties()[propIdx];
if (!KeyframeEffectReadOnly::CanAnimatePropertyOnCompositor(
aFrame,
prop.mProperty)) {
return false;
}
}
}
return true;
}
bool
Bug 1181392 part 5 - Remove use of IsFinishedTransition from AnimationCollection::HasAnimationOfProperty; r=dbaron AnimationCollection::HasAnimationOfProperty uses IsFinishedTransition to filter out transitions that should otherwise be ignored. This is used in the following places: 1. nsLayoutUtils::HasAnimations The is only used by nsIFrame::BuildDisplayListForStackingContext to see if there are any opacity animations For this case, simply returning *current* animations would be sufficient (since finished but filling animations should have already filled in the display opacity) 2. CommonAnimationManager::GetAnimationsForCompositor This should really only return *current* animations--that is, animations that are running or scheduled to run. Finished animations never run on the compositor. Indeed, only *playing* animations run on the compositor but, as we will see in some of the cases below, it is sometimes useful to know that an animation *will* run on the compositor in the near future (e.g. so we can pre-render content). The places where GetAnimationsForCompositor is used are: - When building layers to add animations to layers in nsDisplayList--in this case we skip any animations that aren't playing so if GetAnimationsForCompositor only returned current animations that would be more than sufficient. - In nsLayoutUtils::HasAnimationsForCompositor. This in turn is used: - In ChooseScaleAndSetTransform to see if the transform is being animated on the compositor. If so, it calls nsLayoutUtils::ComputeSuitableScaleForAnimation (which also calls GetAnimationsForCompositor) and passes the result to GetMinAndMaxScaleForAnimationProperty which we have already adjusted in part 4 of this patch series to only deal with *relevant* animations Relevant animations include both current animations and in effect animations but we don't run forwards-filling animations on the compositor so GetAnimationsForCompositor should NOT return them. Current animations should be enough. In fact, playing animations should be enough but we might want to pre-render layers at a suitable size during their delay phase so returning current animations is probably ok. - In nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay to add a fuzz factor to the overflow rect for frames undergoing a transform animation on the compositor. In this case too current animations should be sufficient. - In nsDisplayOpacity::NeedsActiveLayer to say "yes" if we are animating opacity on the compositor. Presumably in this case it would be good to say "yes" if the animation is in the delay phase too (as it currently does). After the animation is finished, we should drop the layer, i.e. current animations should be sufficient. - In nsDisplayTransform::ShouldPrerenderTransformedContent. As with nsDisplayOpacity::NeedsActiveLayer, we only need to pre-render transformed content for animations that are current. - In nsDisplayTransform::GetLayerState. As with nsDisplayOpacity::NeedsActiveLayer, we only need to return active here for current animations. - In nsIFrame::IsTransformed. Here we test the display style to see if there is a transform and also check if transform is being animated on the compositor. As a result, we really only need HasAnimationsForCompositor to return true for animations that are playing--otherwise the display style will tell us if we're transformed or not. Returning true for all current compositor animations (which is a superset of playing), however, should not cause problems (we already return true for even more than that). - In nsIFrame::HasOpacityInternal which is much the same as nsIFrame::IsTransformed and hence current should be fine. 3. AnimationCollection::CanThrottleAnimation Here, HasAnimationOfProperty is used when looking for animations that would disqualify us from throttling the animation by having an out-of-date layer generation or being a transform animation that affects scroll and so requires that we do the occasional main thread sample to update scrollbars. It would seem like current animations are enough here too. One interesting case is where we *had* a compositor animation but it has finished or been cancelled. In that case, the animation won't be current and we should not throttle the animation since we need to take it off its layer. It turns out checking for current animations is still ok in this case too. The reasoning is as follows: - If the animation is newly-finished, we'll pick that up in Animation::CanThrottle and return false then. - If the animation is newly-idle then there are two cases: If the cancelled animation was the only compositor animation then AnimationCollection::CanPerformOnCompositorThread will notice that there are no playing compositor animations and return false and AnimationCollection::CanThrottleAnimation will never be called. If there are other compositor animations running, then AnimationCollection::CanThrottleAnimation will still return false because whatever cancelled the animation will update the animation generation and we'll notice the mismatch between the layer animation generation and the animation generation on the collection. Based on the above analysis it appears that making AnimationCollection::HasAnimationOfProperty return only current animations (and simulatneously renaming it to HasCurrentAnimationOfProperty) is safe. Indeed, in effect, we already do this for transitions but not for animations. This patch generalizes this behavior to all animations. This patch also updates test_animations_omta.html since it was incorrectly testing that a finished opacity animation was still running on the compositor. Finished animations should not run on the compositor and the changes in this patch cause that to happen. The reason we don't just update this test to check for RunningOn.MainThread is that for opacity animations, unlike transform animations, we can't detect if an opacity on a layer was set by animation or not. As a result, for opacity animations we typically test the opacity on either the main thread or compositor in order to allow for the case where an animation-set opacity is still lingering on the compositor.
2015-08-07 06:29:36 +03:00
AnimationCollection::HasCurrentAnimationOfProperty(nsCSSProperty
aProperty) const
{
Bug 1181392 part 5 - Remove use of IsFinishedTransition from AnimationCollection::HasAnimationOfProperty; r=dbaron AnimationCollection::HasAnimationOfProperty uses IsFinishedTransition to filter out transitions that should otherwise be ignored. This is used in the following places: 1. nsLayoutUtils::HasAnimations The is only used by nsIFrame::BuildDisplayListForStackingContext to see if there are any opacity animations For this case, simply returning *current* animations would be sufficient (since finished but filling animations should have already filled in the display opacity) 2. CommonAnimationManager::GetAnimationsForCompositor This should really only return *current* animations--that is, animations that are running or scheduled to run. Finished animations never run on the compositor. Indeed, only *playing* animations run on the compositor but, as we will see in some of the cases below, it is sometimes useful to know that an animation *will* run on the compositor in the near future (e.g. so we can pre-render content). The places where GetAnimationsForCompositor is used are: - When building layers to add animations to layers in nsDisplayList--in this case we skip any animations that aren't playing so if GetAnimationsForCompositor only returned current animations that would be more than sufficient. - In nsLayoutUtils::HasAnimationsForCompositor. This in turn is used: - In ChooseScaleAndSetTransform to see if the transform is being animated on the compositor. If so, it calls nsLayoutUtils::ComputeSuitableScaleForAnimation (which also calls GetAnimationsForCompositor) and passes the result to GetMinAndMaxScaleForAnimationProperty which we have already adjusted in part 4 of this patch series to only deal with *relevant* animations Relevant animations include both current animations and in effect animations but we don't run forwards-filling animations on the compositor so GetAnimationsForCompositor should NOT return them. Current animations should be enough. In fact, playing animations should be enough but we might want to pre-render layers at a suitable size during their delay phase so returning current animations is probably ok. - In nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay to add a fuzz factor to the overflow rect for frames undergoing a transform animation on the compositor. In this case too current animations should be sufficient. - In nsDisplayOpacity::NeedsActiveLayer to say "yes" if we are animating opacity on the compositor. Presumably in this case it would be good to say "yes" if the animation is in the delay phase too (as it currently does). After the animation is finished, we should drop the layer, i.e. current animations should be sufficient. - In nsDisplayTransform::ShouldPrerenderTransformedContent. As with nsDisplayOpacity::NeedsActiveLayer, we only need to pre-render transformed content for animations that are current. - In nsDisplayTransform::GetLayerState. As with nsDisplayOpacity::NeedsActiveLayer, we only need to return active here for current animations. - In nsIFrame::IsTransformed. Here we test the display style to see if there is a transform and also check if transform is being animated on the compositor. As a result, we really only need HasAnimationsForCompositor to return true for animations that are playing--otherwise the display style will tell us if we're transformed or not. Returning true for all current compositor animations (which is a superset of playing), however, should not cause problems (we already return true for even more than that). - In nsIFrame::HasOpacityInternal which is much the same as nsIFrame::IsTransformed and hence current should be fine. 3. AnimationCollection::CanThrottleAnimation Here, HasAnimationOfProperty is used when looking for animations that would disqualify us from throttling the animation by having an out-of-date layer generation or being a transform animation that affects scroll and so requires that we do the occasional main thread sample to update scrollbars. It would seem like current animations are enough here too. One interesting case is where we *had* a compositor animation but it has finished or been cancelled. In that case, the animation won't be current and we should not throttle the animation since we need to take it off its layer. It turns out checking for current animations is still ok in this case too. The reasoning is as follows: - If the animation is newly-finished, we'll pick that up in Animation::CanThrottle and return false then. - If the animation is newly-idle then there are two cases: If the cancelled animation was the only compositor animation then AnimationCollection::CanPerformOnCompositorThread will notice that there are no playing compositor animations and return false and AnimationCollection::CanThrottleAnimation will never be called. If there are other compositor animations running, then AnimationCollection::CanThrottleAnimation will still return false because whatever cancelled the animation will update the animation generation and we'll notice the mismatch between the layer animation generation and the animation generation on the collection. Based on the above analysis it appears that making AnimationCollection::HasAnimationOfProperty return only current animations (and simulatneously renaming it to HasCurrentAnimationOfProperty) is safe. Indeed, in effect, we already do this for transitions but not for animations. This patch generalizes this behavior to all animations. This patch also updates test_animations_omta.html since it was incorrectly testing that a finished opacity animation was still running on the compositor. Finished animations should not run on the compositor and the changes in this patch cause that to happen. The reason we don't just update this test to check for RunningOn.MainThread is that for opacity animations, unlike transform animations, we can't detect if an opacity on a layer was set by animation or not. As a result, for opacity animations we typically test the opacity on either the main thread or compositor in order to allow for the case where an animation-set opacity is still lingering on the compositor.
2015-08-07 06:29:36 +03:00
for (Animation* animation : mAnimations) {
if (animation->HasCurrentEffect() &&
animation->GetEffect()->HasAnimationOfProperty(aProperty)) {
return true;
}
}
return false;
}
/*static*/ nsString
AnimationCollection::PseudoTypeAsString(nsCSSPseudoElements::Type aPseudoType)
{
switch (aPseudoType) {
case nsCSSPseudoElements::ePseudo_before:
return NS_LITERAL_STRING("::before");
case nsCSSPseudoElements::ePseudo_after:
return NS_LITERAL_STRING("::after");
default:
MOZ_ASSERT(aPseudoType == nsCSSPseudoElements::ePseudo_NotPseudoElement,
"Unexpected pseudo type");
return EmptyString();
}
}
mozilla::dom::Element*
AnimationCollection::GetElementToRestyle() const
{
if (IsForElement()) {
return mElement;
}
nsIFrame* primaryFrame = mElement->GetPrimaryFrame();
if (!primaryFrame) {
return nullptr;
}
nsIFrame* pseudoFrame;
if (IsForBeforePseudo()) {
pseudoFrame = nsLayoutUtils::GetBeforeFrame(primaryFrame);
} else if (IsForAfterPseudo()) {
pseudoFrame = nsLayoutUtils::GetAfterFrame(primaryFrame);
} else {
MOZ_ASSERT(false, "unknown mElementProperty");
return nullptr;
}
if (!pseudoFrame) {
return nullptr;
}
return pseudoFrame->GetContent()->AsElement();
}
/* static */ void
AnimationCollection::LogAsyncAnimationFailure(nsCString& aMessage,
const nsIContent* aContent)
{
if (aContent) {
aMessage.AppendLiteral(" [");
aMessage.Append(nsAtomCString(aContent->NodeInfo()->NameAtom()));
nsIAtom* id = aContent->GetID();
if (id) {
aMessage.AppendLiteral(" with id '");
aMessage.Append(nsAtomCString(aContent->GetID()));
aMessage.Append('\'');
}
aMessage.Append(']');
}
aMessage.Append('\n');
printf_stderr("%s", aMessage.get());
}
/*static*/ void
AnimationCollection::PropertyDtor(void *aObject, nsIAtom *aPropertyName,
void *aPropertyValue, void *aData)
{
AnimationCollection* collection =
static_cast<AnimationCollection*>(aPropertyValue);
#ifdef DEBUG
MOZ_ASSERT(!collection->mCalledPropertyDtor, "can't call dtor twice");
collection->mCalledPropertyDtor = true;
#endif
{
nsAutoAnimationMutationBatch mb(collection->mElement->OwnerDoc());
for (size_t animIdx = collection->mAnimations.Length(); animIdx-- != 0; ) {
collection->mAnimations[animIdx]->CancelFromStyle();
}
}
delete collection;
}
void
AnimationCollection::Tick()
{
for (size_t animIdx = 0, animEnd = mAnimations.Length();
animIdx != animEnd; animIdx++) {
mAnimations[animIdx]->Tick();
}
}
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
void
Bug 1188251 part 10 - Remove throttling from EnsureStyleRuleFor; r=dholbert EnsureStyleRuleFor contains logic for performing throttled updates to the style rule but it is only used in one case: inside nsTransitionManager::UpdateCascadeResults to determine what properties are being animated by CSS animations. We would like to remove throttling logic from EnsureStyleRuleFor altogether but if that one case where it is currently used is run on every tick then removing this logic could effectively mean we end up updating the style rule on every tick. Fortunately nsTransitionManager::UpdateCascadeResults is only called in the following cases: 1. From nsTransitionManager::StyleContextChanged (via TransitionManager::UpdateCascadeResultsWithTransitions), when we are processing style changes for transitions. 2. From AnimationCollection::EnsureStyleRuleFor (via nsAnimationManager::MaybeUpdateCascadeResults and nsTransitionManager::UpdateCascadeResultsWithAnimations), when we are updating the animation style rule from CSS animations. 3. From nsAnimationManager::CheckAnimationRule (via TransitionManager::UpdateCascadeResultsWithAnimationsToBeDestroyed), when we are processing style changes for CSS animations. None of these things should be happenning on a regular throttle-able tick so by removing this logic we shouldn't be causing any additional work. I have verified, using a test case that combines transitions and animations on the same property, that we have the same behavior with regard to calling EnsureStyleRuleFor both before and after this patch (specifically we avoid calling it altogether while running only the transition but when the animation starts and clobbers the transition we end up calling EnsureStyleRuleFor once on each tick).
2015-08-18 10:11:55 +03:00
AnimationCollection::EnsureStyleRuleFor(TimeStamp aRefreshTime)
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
{
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).
2015-08-17 07:59:44 +03:00
mHasPendingAnimationRestyle = false;
if (!mStyleChanging) {
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
mStyleRuleRefreshTime = aRefreshTime;
return;
}
if (!mStyleRuleRefreshTime.IsNull() &&
mStyleRuleRefreshTime == aRefreshTime) {
// mStyleRule may be null and valid, if we have no style to apply.
return;
}
if (mManager->IsAnimationManager()) {
// Update cascade results before updating the style rule, since the
// cascade results can influence the style rule.
static_cast<nsAnimationManager*>(mManager)->MaybeUpdateCascadeResults(this);
}
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
mStyleRuleRefreshTime = aRefreshTime;
mStyleRule = nullptr;
// We'll set mStyleChanging to true below if necessary.
mStyleChanging = false;
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
// If multiple animations specify behavior for the same property the
// animation which occurs last in the value of animation-name wins.
// As a result, we iterate from last animation to first and, if a
// property has already been set, we don't leave it.
nsCSSPropertySet properties;
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
for (size_t animIdx = mAnimations.Length(); animIdx-- != 0; ) {
mAnimations[animIdx]->ComposeStyle(mStyleRule, properties, mStyleChanging);
}
}
Bug 1025709 part 4 - Move EnsureStyleRuleFor from ElementTransitions and ElementAnimations to CommonElementAnimationData; r=heycam Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method. The ElementAnimations version is a more general of the ElementTransitions one with the exception that the ElementTransitions version checks for finished transitions. This patch moves the code from ElementAnimations to CommonElementAnimationData with one minor change: adding the checks for finished transitions. The ElementTransitions version is removed. Since the ElementAnimations version contains a second parameter, aIsThrottled, callers of ElementTransitions must include this extra parameter. In a subsequent patch we add an enum for this parameter to make call sites easier to read. The ElementAnimations version also sets the mNeedsRefreshes member so at the same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore, since the ElementAnimations version which we have adopted returns early if mNeedsRefreshes is false, this patch ensures that when we call EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set mNeedsRefreshes to true first. Another difference to account for is that the ElementTransitions version of EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to it) where as the ElementAnimations version only creates the rule when necessary so we need to add a check to ElementTransitions::WalkTransitionRule that mStyleRule is actually set before using it.
2014-06-20 07:39:24 +04:00
void
AnimationCollection::ClearIsRunningOnCompositor(nsCSSProperty aProperty)
{
for (Animation* anim : mAnimations) {
dom::KeyframeEffectReadOnly* effect = anim->GetEffect();
if (effect) {
effect->SetIsRunningOnCompositor(aProperty, false);
}
}
}
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).
2015-08-17 07:59:44 +03:00
void
AnimationCollection::RequestRestyle(RestyleType aRestyleType)
{
MOZ_ASSERT(IsForElement() || IsForBeforePseudo() || IsForAfterPseudo(),
"Unexpected mElementProperty; might restyle too much");
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).
2015-08-17 07:59:44 +03:00
nsPresContext* presContext = mManager->PresContext();
if (!presContext) {
// Pres context will be null after the manager is disconnected.
return;
}
// Steps for Restyle::Layer:
if (aRestyleType == RestyleType::Layer) {
mStyleRuleRefreshTime = TimeStamp();
mStyleChanging = true;
// Prompt layers to re-sync their animations.
presContext->ClearLastStyleUpdateForAllAnimations();
presContext->RestyleManager()->IncrementAnimationGeneration();
UpdateAnimationGeneration(presContext);
}
// Steps for RestyleType::Standard and above:
if (mHasPendingAnimationRestyle) {
return;
}
if (aRestyleType >= RestyleType::Standard) {
mHasPendingAnimationRestyle = true;
PostRestyleForAnimation(presContext);
return;
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).
2015-08-17 07:59:44 +03:00
}
// Steps for RestyleType::Throttled:
MOZ_ASSERT(aRestyleType == RestyleType::Throttled,
"Should have already handled all non-throttled restyles");
presContext->Document()->SetNeedStyleFlush();
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).
2015-08-17 07:59:44 +03:00
}
void
AnimationCollection::UpdateAnimationGeneration(nsPresContext* aPresContext)
{
mAnimationGeneration =
aPresContext->RestyleManager()->GetAnimationGeneration();
}
void
AnimationCollection::UpdateCheckGeneration(
nsPresContext* aPresContext)
{
mCheckGeneration =
aPresContext->RestyleManager()->GetAnimationGeneration();
}
bool
AnimationCollection::HasCurrentAnimations() const
{
for (size_t animIdx = mAnimations.Length(); animIdx-- != 0; ) {
if (mAnimations[animIdx]->HasCurrentEffect()) {
return true;
}
}
return false;
}
bool
AnimationCollection::HasCurrentAnimationsForProperties(
const nsCSSProperty* aProperties,
size_t aPropertyCount) const
{
for (size_t animIdx = mAnimations.Length(); animIdx-- != 0; ) {
const Animation& anim = *mAnimations[animIdx];
const KeyframeEffectReadOnly* effect = anim.GetEffect();
if (effect &&
effect->IsCurrent() &&
effect->HasAnimationOfProperties(aProperties, aPropertyCount)) {
return true;
}
}
return false;
}
nsPresContext*
OwningElementRef::GetRenderedPresContext() const
{
if (!mElement) {
return nullptr;
}
nsIDocument* doc = mElement->GetComposedDoc();
if (!doc) {
return nullptr;
}
nsIPresShell* shell = doc->GetShell();
if (!shell) {
return nullptr;
}
return shell->GetPresContext();
}
} // namespace mozilla