gecko-dev/layout/style/nsTransitionManager.cpp

906 строки
34 KiB
C++
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* 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/. */
/* Code to start and animate CSS transitions. */
#include "nsTransitionManager.h"
#include "nsAnimationManager.h"
#include "mozilla/dom/CSSTransitionBinding.h"
#include "nsIContent.h"
#include "nsStyleContext.h"
#include "mozilla/MemoryReporting.h"
#include "mozilla/TimeStamp.h"
#include "nsRefreshDriver.h"
#include "nsRuleProcessorData.h"
#include "nsRuleWalker.h"
#include "nsCSSPropertySet.h"
#include "mozilla/EventDispatcher.h"
#include "mozilla/StyleAnimationValue.h"
#include "mozilla/dom/DocumentTimeline.h"
#include "mozilla/dom/Element.h"
#include "nsIFrame.h"
#include "Layers.h"
#include "FrameLayerBuilder.h"
#include "nsCSSProps.h"
#include "nsDisplayList.h"
#include "nsStyleChangeList.h"
#include "nsStyleSet.h"
#include "RestyleManager.h"
#include "nsDOMMutationObserver.h"
using mozilla::TimeStamp;
using mozilla::TimeDuration;
using mozilla::dom::Animation;
using mozilla::dom::KeyframeEffectReadOnly;
using namespace mozilla;
using namespace mozilla::css;
double
ElementPropertyTransition::CurrentValuePortion() const
{
MOZ_ASSERT(!GetLocalTime().IsNull(),
"Getting the value portion of an animation that's not being "
"sampled");
// Transitions use a fill mode of 'backwards' so GetComputedTiming will
// never return a null time progress due to being *before* the animation
// interval. However, it might be possible that we're behind on flushing
// causing us to get called *after* the animation interval. So, just in
// case, we override the fill mode to 'both' to ensure the progress
// is never null.
AnimationTiming timingToUse = mTiming;
timingToUse.mFillMode = NS_STYLE_ANIMATION_FILL_MODE_BOTH;
ComputedTiming computedTiming = GetComputedTiming(&timingToUse);
MOZ_ASSERT(computedTiming.mProgress != ComputedTiming::kNullProgress,
"Got a null progress for a fill mode of 'both'");
MOZ_ASSERT(mProperties.Length() == 1,
"Should have one animation property for a transition");
MOZ_ASSERT(mProperties[0].mSegments.Length() == 1,
"Animation property should have one segment for a transition");
return mProperties[0].mSegments[0].mTimingFunction
.GetValue(computedTiming.mProgress);
}
////////////////////////// CSSTransition ////////////////////////////
JSObject*
CSSTransition::WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto)
{
return dom::CSSTransitionBinding::Wrap(aCx, this, aGivenProto);
}
void
CSSTransition::GetTransitionProperty(nsString& aRetVal) const
{
// Once we make the effect property settable (bug 1049975) we will need
// to store the transition property on the CSSTransition itself but for
// now we can just query the effect.
MOZ_ASSERT(mEffect && mEffect->AsTransition(),
"Transitions should have a transition effect");
nsCSSProperty prop = mEffect->AsTransition()->TransitionProperty();
aRetVal = NS_ConvertUTF8toUTF16(nsCSSProps::GetStringValue(prop));
}
AnimationPlayState
CSSTransition::PlayStateFromJS() const
{
FlushStyle();
return Animation::PlayStateFromJS();
}
void
CSSTransition::PlayFromJS(ErrorResult& aRv)
{
FlushStyle();
Animation::PlayFromJS(aRv);
}
CommonAnimationManager*
CSSTransition::GetAnimationManager() const
{
nsPresContext* context = GetPresContext();
if (!context) {
return nullptr;
}
return context->TransitionManager();
}
void
CSSTransition::UpdateTiming(SeekFlag aSeekFlag, SyncNotifyFlag aSyncNotifyFlag)
{
if (mNeedsNewAnimationIndexWhenRun &&
PlayState() != AnimationPlayState::Idle) {
mAnimationIndex = sNextAnimationIndex++;
mNeedsNewAnimationIndexWhenRun = false;
}
Animation::UpdateTiming(aSeekFlag, aSyncNotifyFlag);
}
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
void
CSSTransition::QueueEvents()
{
AnimationPlayState playState = PlayState();
bool newlyFinished = !mWasFinishedOnLastTick &&
playState == AnimationPlayState::Finished;
mWasFinishedOnLastTick = playState == AnimationPlayState::Finished;
if (!newlyFinished || !mEffect || !mOwningElement.IsSet()) {
return;
}
dom::Element* owningElement;
nsCSSPseudoElements::Type owningPseudoType;
mOwningElement.GetElement(owningElement, owningPseudoType);
MOZ_ASSERT(owningElement, "Owning element should be set");
nsPresContext* presContext = mOwningElement.GetRenderedPresContext();
if (!presContext) {
return;
}
nsTransitionManager* manager = presContext->TransitionManager();
manager->QueueEvent(TransitionEventInfo(owningElement, owningPseudoType,
TransitionProperty(),
mEffect->Timing()
.mIterationDuration,
AnimationTimeToTimeStamp(EffectEnd()),
this));
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
}
bool
CSSTransition::HasEndEventToQueue() const
{
if (!mEffect) {
return false;
}
return !mWasFinishedOnLastTick &&
PlayState() == AnimationPlayState::Finished;
}
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
void
CSSTransition::Tick()
{
Animation::Tick();
QueueEvents();
}
nsCSSProperty
CSSTransition::TransitionProperty() const
{
// FIXME: Once we support replacing/removing the effect (bug 1049975)
// we'll need to store the original transition property so we keep
// returning the same value in that case.
dom::KeyframeEffectReadOnly* effect = GetEffect();
MOZ_ASSERT(effect && effect->AsTransition(),
"Transition should have a transition effect");
return effect->AsTransition()->TransitionProperty();
}
bool
CSSTransition::HasLowerCompositeOrderThan(const Animation& aOther) const
{
// 0. Object-equality case
if (&aOther == this) {
return false;
}
// 1. Transitions sort lowest
const CSSTransition* otherTransition = aOther.AsCSSTransition();
if (!otherTransition) {
return true;
}
// 2. CSS transitions that correspond to a transition-property property sort
// lower than CSS transitions owned by script.
if (!IsTiedToMarkup()) {
return !otherTransition->IsTiedToMarkup() ?
Animation::HasLowerCompositeOrderThan(aOther) :
false;
}
if (!otherTransition->IsTiedToMarkup()) {
return true;
}
// 3. Sort by document order
if (!mOwningElement.Equals(otherTransition->mOwningElement)) {
return mOwningElement.LessThan(otherTransition->mOwningElement);
}
// 4. (Same element and pseudo): Sort by transition generation
if (mAnimationIndex != otherTransition->mAnimationIndex) {
return mAnimationIndex < otherTransition->mAnimationIndex;
}
// 5. (Same transition generation): Sort by transition property
return nsCSSProps::GetStringValue(TransitionProperty()) <
nsCSSProps::GetStringValue(otherTransition->TransitionProperty());
}
////////////////////////// nsTransitionManager ////////////////////////////
NS_IMPL_CYCLE_COLLECTION(nsTransitionManager, mEventDispatcher)
NS_IMPL_CYCLE_COLLECTING_ADDREF(nsTransitionManager)
NS_IMPL_CYCLE_COLLECTING_RELEASE(nsTransitionManager)
NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(nsTransitionManager)
NS_INTERFACE_MAP_ENTRY(nsIStyleRuleProcessor)
NS_INTERFACE_MAP_ENTRY(nsISupports)
NS_INTERFACE_MAP_END
void
nsTransitionManager::StyleContextChanged(dom::Element *aElement,
nsStyleContext *aOldStyleContext,
nsRefPtr<nsStyleContext>* aNewStyleContext /* inout */)
{
nsStyleContext* newStyleContext = *aNewStyleContext;
NS_PRECONDITION(aOldStyleContext->GetPseudo() == newStyleContext->GetPseudo(),
"pseudo type mismatch");
if (mInAnimationOnlyStyleUpdate) {
// If we're doing an animation-only style update, return, since the
// purpose of an animation-only style update is to update only the
// animation styles so that we don't consider style changes
// resulting from changes in the animation time for starting a
// transition.
return;
}
if (!mPresContext->IsDynamic()) {
// For print or print preview, ignore transitions.
return;
}
if (aOldStyleContext->HasPseudoElementData() !=
newStyleContext->HasPseudoElementData()) {
// If the old style context and new style context differ in terms of
// whether they're inside ::first-letter, ::first-line, or similar,
// bail. We can't hit this codepath for normal style changes
// involving moving frames around the boundaries of these
// pseudo-elements since we don't call StyleContextChanged from
// ReparentStyleContext. However, we can hit this codepath during
// the handling of transitions that start across reframes.
//
// While there isn't an easy *perfect* way to handle this case, err
// on the side of missing some transitions that we ought to have
// rather than having bogus transitions that we shouldn't.
//
// We could consider changing this handling, although it's worth
// thinking about whether the code below could do anything weird in
// this case.
return;
}
// NOTE: Things in this function (and ConsiderStartingTransition)
// should never call PeekStyleData because we don't preserve gotten
// structs across reframes.
// Return sooner (before the startedAny check below) for the most
// common case: no transitions specified or running.
const nsStyleDisplay *disp = newStyleContext->StyleDisplay();
nsCSSPseudoElements::Type pseudoType = newStyleContext->GetPseudoType();
if (pseudoType != nsCSSPseudoElements::ePseudo_NotPseudoElement) {
if (pseudoType != nsCSSPseudoElements::ePseudo_before &&
pseudoType != nsCSSPseudoElements::ePseudo_after) {
return;
}
NS_ASSERTION((pseudoType == nsCSSPseudoElements::ePseudo_before &&
aElement->NodeInfo()->NameAtom() == nsGkAtoms::mozgeneratedcontentbefore) ||
(pseudoType == nsCSSPseudoElements::ePseudo_after &&
aElement->NodeInfo()->NameAtom() == nsGkAtoms::mozgeneratedcontentafter),
"Unexpected aElement coming through");
// Else the element we want to use from now on is the element the
// :before or :after is attached to.
aElement = aElement->GetParent()->AsElement();
}
AnimationCollection* collection = GetAnimations(aElement, pseudoType, false);
if (!collection &&
disp->mTransitionPropertyCount == 1 &&
disp->mTransitions[0].GetCombinedDuration() <= 0.0f) {
return;
}
if (collection &&
collection->mCheckGeneration ==
mPresContext->RestyleManager()->GetAnimationGeneration()) {
// When we start a new transition, we immediately post a restyle.
// If the animation generation on the collection is current, that
// means *this* is that restyle, since we bump the animation
// generation on the restyle manager whenever there's a real style
// change (i.e., one where mInAnimationOnlyStyleUpdate isn't true,
// which causes us to return above). Thus we shouldn't do anything.
return;
}
if (newStyleContext->GetParent() &&
newStyleContext->GetParent()->HasPseudoElementData()) {
// Ignore transitions on things that inherit properties from
// pseudo-elements.
// FIXME (Bug 522599): Add tests for this.
return;
}
NS_WARN_IF_FALSE(!nsLayoutUtils::AreAsyncAnimationsEnabled() ||
mPresContext->RestyleManager()->
ThrottledAnimationStyleIsUpToDate(),
"throttled animations not up to date");
// Compute what the css-transitions spec calls the "after-change
// style", which is the new style without any data from transitions,
// but still inheriting from data that contains transitions that are
// not stopping or starting right now.
nsRefPtr<nsStyleContext> afterChangeStyle;
if (collection) {
nsStyleSet* styleSet = mPresContext->StyleSet();
afterChangeStyle =
styleSet->ResolveStyleWithoutAnimation(aElement, newStyleContext,
eRestyle_CSSTransitions);
} else {
afterChangeStyle = newStyleContext;
}
nsAutoAnimationMutationBatch mb(aElement->OwnerDoc());
// Per http://lists.w3.org/Archives/Public/www-style/2009Aug/0109.html
// I'll consider only the transitions from the number of items in
// 'transition-property' on down, and later ones will override earlier
// ones (tracked using |whichStarted|).
bool startedAny = false;
nsCSSPropertySet whichStarted;
for (uint32_t i = disp->mTransitionPropertyCount; i-- != 0; ) {
const StyleTransition& t = disp->mTransitions[i];
// Check the combined duration (combination of delay and duration)
// first, since it defaults to zero, which means we can ignore the
// transition.
if (t.GetCombinedDuration() > 0.0f) {
// We might have something to transition. See if any of the
// properties in question changed and are animatable.
// FIXME: Would be good to find a way to share code between this
// interpretation of transition-property and the one below.
nsCSSProperty property = t.GetProperty();
if (property == eCSSPropertyExtra_no_properties ||
property == eCSSPropertyExtra_variable ||
property == eCSSProperty_UNKNOWN) {
// Nothing to do, but need to exclude this from cases below.
} else if (property == eCSSPropertyExtra_all_properties) {
for (nsCSSProperty p = nsCSSProperty(0);
p < eCSSProperty_COUNT_no_shorthands;
p = nsCSSProperty(p + 1)) {
ConsiderStartingTransition(p, t, aElement, collection,
aOldStyleContext, afterChangeStyle,
&startedAny, &whichStarted);
}
} else if (nsCSSProps::IsShorthand(property)) {
CSSPROPS_FOR_SHORTHAND_SUBPROPERTIES(
subprop, property, nsCSSProps::eEnabledForAllContent) {
ConsiderStartingTransition(*subprop, t, aElement, collection,
aOldStyleContext, afterChangeStyle,
&startedAny, &whichStarted);
}
} else {
ConsiderStartingTransition(property, t, aElement, collection,
aOldStyleContext, afterChangeStyle,
&startedAny, &whichStarted);
}
}
}
// Stop any transitions for properties that are no longer in
// 'transition-property', including finished transitions.
// Also stop any transitions (and remove any finished transitions)
// for properties that just changed (and are still in the set of
// properties to transition), but for which we didn't just start the
// transition. This can happen delay and duration are both zero, or
// because the new value is not interpolable.
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles Since bug 960465 patch 14, we've retained finished transitions in order to handle the issues described in https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The code that did this made the assumption that the transition manager is notified of the full sequence of style changes that happen to an element. However, when an element becomes part of a display:none subtree and then later becomes displayed again, the transition manager is not notified of a style change when it becomes displayed again (when we do not have the old style context). This patch introduces code to prune the finished transitions when that happens. This really fixes only part of the set of problems described in bug 1158431, which also affect running transitions. However, it's the part of that set that was a regression from bug 960465, which introduced the retention of finished transitions, and which makes these issues substantially easier to hit. I'd like to fix this part quickly because it's a regression and we should backport the fix. Without the patch, I confirmed that the following two tests fail: INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1 INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5 With the patch, all the added tests pass. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
// Note that we also do the latter set of work in
// nsTransitionManager::PruneCompletedTransitions.
if (collection) {
bool checkProperties =
disp->mTransitions[0].GetProperty() != eCSSPropertyExtra_all_properties;
nsCSSPropertySet allTransitionProperties;
if (checkProperties) {
for (uint32_t i = disp->mTransitionPropertyCount; i-- != 0; ) {
const StyleTransition& t = disp->mTransitions[i];
// FIXME: Would be good to find a way to share code between this
// interpretation of transition-property and the one above.
nsCSSProperty property = t.GetProperty();
if (property == eCSSPropertyExtra_no_properties ||
property == eCSSPropertyExtra_variable ||
property == eCSSProperty_UNKNOWN) {
// Nothing to do, but need to exclude this from cases below.
} else if (property == eCSSPropertyExtra_all_properties) {
for (nsCSSProperty p = nsCSSProperty(0);
p < eCSSProperty_COUNT_no_shorthands;
p = nsCSSProperty(p + 1)) {
allTransitionProperties.AddProperty(p);
}
} else if (nsCSSProps::IsShorthand(property)) {
CSSPROPS_FOR_SHORTHAND_SUBPROPERTIES(
subprop, property, nsCSSProps::eEnabledForAllContent) {
allTransitionProperties.AddProperty(*subprop);
}
} else {
allTransitionProperties.AddProperty(property);
}
}
}
AnimationPtrArray& animations = collection->mAnimations;
size_t i = animations.Length();
MOZ_ASSERT(i != 0, "empty transitions list?");
StyleAnimationValue currentValue;
do {
--i;
Animation* anim = animations[i];
dom::KeyframeEffectReadOnly* effect = anim->GetEffect();
MOZ_ASSERT(effect && effect->Properties().Length() == 1,
"Should have one animation property for a transition");
MOZ_ASSERT(effect && effect->Properties()[0].mSegments.Length() == 1,
"Animation property should have one segment for a transition");
const AnimationProperty& prop = effect->Properties()[0];
const AnimationPropertySegment& segment = prop.mSegments[0];
// properties no longer in 'transition-property'
if ((checkProperties &&
!allTransitionProperties.HasProperty(prop.mProperty)) ||
// properties whose computed values changed but for which we
// did not start a new transition (because delay and
// duration are both zero, or because the new value is not
// interpolable); a new transition would have segment.mToValue
// matching currentValue
!ExtractComputedValueForTransition(prop.mProperty, afterChangeStyle,
currentValue) ||
currentValue != segment.mToValue) {
// stop the transition
if (anim->HasCurrentEffect()) {
collection->UpdateAnimationGeneration(mPresContext);
}
anim->CancelFromStyle();
animations.RemoveElementAt(i);
}
} while (i != 0);
if (animations.IsEmpty()) {
collection->Destroy();
collection = nullptr;
}
}
MOZ_ASSERT(!startedAny || collection,
"must have element transitions if we started any transitions");
if (collection) {
UpdateCascadeResultsWithTransitions(collection);
// Set the style rule refresh time to null so that EnsureStyleRuleFor
// creates a new style rule if we started *or* stopped transitions.
collection->mStyleRuleRefreshTime = TimeStamp();
collection->UpdateCheckGeneration(mPresContext);
collection->mNeedsRefreshes = true;
TimeStamp now = mPresContext->RefreshDriver()->MostRecentRefresh();
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);
}
// We want to replace the new style context with the after-change style.
*aNewStyleContext = afterChangeStyle;
if (collection) {
// Since we have transition styles, we have to undo this replacement.
// The check of collection->mCheckGeneration against the restyle
// manager's GetAnimationGeneration() will ensure that we don't go
// through the rest of this function again when we do.
collection->PostRestyleForAnimation(mPresContext);
}
}
void
nsTransitionManager::ConsiderStartingTransition(
nsCSSProperty aProperty,
const StyleTransition& aTransition,
dom::Element* aElement,
AnimationCollection*& aElementTransitions,
nsStyleContext* aOldStyleContext,
nsStyleContext* aNewStyleContext,
bool* aStartedAny,
nsCSSPropertySet* aWhichStarted)
{
// IsShorthand itself will assert if aProperty is not a property.
MOZ_ASSERT(!nsCSSProps::IsShorthand(aProperty),
"property out of range");
NS_ASSERTION(!aElementTransitions ||
aElementTransitions->mElement == aElement, "Element mismatch");
if (aWhichStarted->HasProperty(aProperty)) {
// A later item in transition-property already started a
// transition for this property, so we ignore this one.
// See comment above and
// http://lists.w3.org/Archives/Public/www-style/2009Aug/0109.html .
return;
}
if (nsCSSProps::kAnimTypeTable[aProperty] == eStyleAnimType_None) {
return;
}
dom::DocumentTimeline* timeline = aElement->OwnerDoc()->Timeline();
StyleAnimationValue startValue, endValue, dummyValue;
bool haveValues =
ExtractComputedValueForTransition(aProperty, aOldStyleContext,
startValue) &&
ExtractComputedValueForTransition(aProperty, aNewStyleContext,
endValue);
bool haveChange = startValue != endValue;
bool shouldAnimate =
haveValues &&
haveChange &&
// Check that we can interpolate between these values
// (If this is ever a performance problem, we could add a
// CanInterpolate method, but it seems fine for now.)
StyleAnimationValue::Interpolate(aProperty, startValue, endValue,
0.5, dummyValue);
bool haveCurrentTransition = false;
size_t currentIndex = nsTArray<ElementPropertyTransition>::NoIndex;
const ElementPropertyTransition *oldPT = nullptr;
if (aElementTransitions) {
AnimationPtrArray& animations = aElementTransitions->mAnimations;
for (size_t i = 0, i_end = animations.Length(); i < i_end; ++i) {
const ElementPropertyTransition *iPt =
animations[i]->GetEffect()->AsTransition();
if (iPt->TransitionProperty() == aProperty) {
haveCurrentTransition = true;
currentIndex = i;
oldPT = iPt;
break;
}
}
}
// If we got a style change that changed the value to the endpoint
// of the currently running transition, we don't want to interrupt
// its timing function.
// This needs to be before the !shouldAnimate && haveCurrentTransition
// case below because we might be close enough to the end of the
// transition that the current value rounds to the final value. In
// this case, we'll end up with shouldAnimate as false (because
// there's no value change), but we need to return early here rather
// than cancel the running transition because shouldAnimate is false!
//
// Likewise, if we got a style change that changed the value to the
// endpoint of our finished transition, we also don't want to start
// a new transition for the reasons described in
// https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html .
MOZ_ASSERT(!oldPT || oldPT->Properties()[0].mSegments.Length() == 1,
"Should have one animation property segment for a transition");
if (haveCurrentTransition && haveValues &&
oldPT->Properties()[0].mSegments[0].mToValue == endValue) {
// GetAnimationRule already called RestyleForAnimation.
return;
}
if (!shouldAnimate) {
if (haveCurrentTransition) {
// We're in the middle of a transition, and just got a non-transition
// style change to something that we can't animate. This might happen
// because we got a non-transition style change changing to the current
// in-progress value (which is particularly easy to cause when we're
// currently in the 'transition-delay'). It also might happen because we
// just got a style change to a value that can't be interpolated.
AnimationPtrArray& animations = aElementTransitions->mAnimations;
animations[currentIndex]->CancelFromStyle();
oldPT = nullptr; // Clear pointer so it doesn't dangle
animations.RemoveElementAt(currentIndex);
aElementTransitions->UpdateAnimationGeneration(mPresContext);
if (animations.IsEmpty()) {
aElementTransitions->Destroy();
// |aElementTransitions| is now a dangling pointer!
aElementTransitions = nullptr;
}
// GetAnimationRule already called RestyleForAnimation.
}
return;
}
const nsTimingFunction &tf = aTransition.GetTimingFunction();
float delay = aTransition.GetDelay();
float duration = aTransition.GetDuration();
if (duration < 0.0) {
// The spec says a negative duration is treated as zero.
duration = 0.0;
}
StyleAnimationValue startForReversingTest = startValue;
double reversePortion = 1.0;
// If the new transition reverses an existing one, we'll need to
// handle the timing differently.
if (haveCurrentTransition &&
aElementTransitions->mAnimations[currentIndex]->HasCurrentEffect() &&
oldPT->mStartForReversingTest == endValue) {
// Compute the appropriate negative transition-delay such that right
// now we'd end up at the current position.
double valuePortion =
oldPT->CurrentValuePortion() * oldPT->mReversePortion +
(1.0 - oldPT->mReversePortion);
// A timing function with negative y1 (or y2!) might make
// valuePortion negative. In this case, we still want to apply our
// reversing logic based on relative distances, not make duration
// negative.
if (valuePortion < 0.0) {
valuePortion = -valuePortion;
}
// A timing function with y2 (or y1!) greater than one might
// advance past its terminal value. It's probably a good idea to
// clamp valuePortion to be at most one to preserve the invariant
// that a transition will complete within at most its specified
// time.
if (valuePortion > 1.0) {
valuePortion = 1.0;
}
// Negative delays are essentially part of the transition
// function, so reduce them along with the duration, but don't
// reduce positive delays.
if (delay < 0.0f) {
delay *= valuePortion;
}
duration *= valuePortion;
startForReversingTest = oldPT->Properties()[0].mSegments[0].mToValue;
reversePortion = valuePortion;
}
AnimationTiming timing;
timing.mIterationDuration = TimeDuration::FromMilliseconds(duration);
timing.mDelay = TimeDuration::FromMilliseconds(delay);
timing.mIterationCount = 1;
timing.mDirection = NS_STYLE_ANIMATION_DIRECTION_NORMAL;
timing.mFillMode = NS_STYLE_ANIMATION_FILL_MODE_BACKWARDS;
nsRefPtr<ElementPropertyTransition> pt =
new ElementPropertyTransition(aElement->OwnerDoc(), aElement,
aNewStyleContext->GetPseudoType(), timing);
pt->mStartForReversingTest = startForReversingTest;
pt->mReversePortion = reversePortion;
AnimationProperty& prop = *pt->Properties().AppendElement();
prop.mProperty = aProperty;
prop.mWinsInCascade = true;
AnimationPropertySegment& segment = *prop.mSegments.AppendElement();
segment.mFromValue = startValue;
segment.mToValue = endValue;
segment.mFromKey = 0;
segment.mToKey = 1;
segment.mTimingFunction.Init(tf);
nsRefPtr<CSSTransition> animation =
new CSSTransition(mPresContext->Document()->GetScopeObject());
animation->SetOwningElement(
OwningElementRef(*aElement, aNewStyleContext->GetPseudoType()));
animation->SetTimeline(timeline);
animation->SetCreationSequence(
mPresContext->RestyleManager()->GetAnimationGeneration());
// The order of the following two calls is important since PlayFromStyle
// will add the animation to the PendingAnimationTracker of its effect's
// document. When we come to make effect writeable (bug 1049975) we should
// remove this dependency.
animation->SetEffect(pt);
animation->PlayFromStyle();
if (!aElementTransitions) {
aElementTransitions =
GetAnimations(aElement, aNewStyleContext->GetPseudoType(), true);
if (!aElementTransitions) {
NS_WARNING("allocating CommonAnimationManager failed");
return;
}
}
AnimationPtrArray& animations = aElementTransitions->mAnimations;
#ifdef DEBUG
for (size_t i = 0, i_end = animations.Length(); i < i_end; ++i) {
MOZ_ASSERT(
i == currentIndex ||
(animations[i]->GetEffect() &&
animations[i]->GetEffect()->AsTransition()->TransitionProperty()
!= aProperty),
"duplicate transitions for property");
}
#endif
if (haveCurrentTransition) {
animations[currentIndex]->CancelFromStyle();
oldPT = nullptr; // Clear pointer so it doesn't dangle
animations[currentIndex] = animation;
} else {
if (!animations.AppendElement(animation)) {
NS_WARNING("out of memory");
return;
}
}
aElementTransitions->UpdateAnimationGeneration(mPresContext);
*aStartedAny = true;
aWhichStarted->AddProperty(aProperty);
}
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles Since bug 960465 patch 14, we've retained finished transitions in order to handle the issues described in https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The code that did this made the assumption that the transition manager is notified of the full sequence of style changes that happen to an element. However, when an element becomes part of a display:none subtree and then later becomes displayed again, the transition manager is not notified of a style change when it becomes displayed again (when we do not have the old style context). This patch introduces code to prune the finished transitions when that happens. This really fixes only part of the set of problems described in bug 1158431, which also affect running transitions. However, it's the part of that set that was a regression from bug 960465, which introduced the retention of finished transitions, and which makes these issues substantially easier to hit. I'd like to fix this part quickly because it's a regression and we should backport the fix. Without the patch, I confirmed that the following two tests fail: INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1 INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5 With the patch, all the added tests pass. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
void
nsTransitionManager::PruneCompletedTransitions(mozilla::dom::Element* aElement,
nsCSSPseudoElements::Type
aPseudoType,
nsStyleContext* aNewStyleContext)
{
AnimationCollection* collection = GetAnimations(aElement, aPseudoType, false);
if (!collection) {
return;
}
// Remove any finished transitions whose style doesn't match the new
// style.
// This is similar to some of the work that happens near the end of
// nsTransitionManager::StyleContextChanged.
// FIXME (bug 1158431): Really, we should also cancel running
// transitions whose destination doesn't match as well.
AnimationPtrArray& animations = collection->mAnimations;
size_t i = animations.Length();
MOZ_ASSERT(i != 0, "empty transitions list?");
do {
--i;
Animation* anim = animations[i];
if (anim->HasCurrentEffect()) {
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles Since bug 960465 patch 14, we've retained finished transitions in order to handle the issues described in https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The code that did this made the assumption that the transition manager is notified of the full sequence of style changes that happen to an element. However, when an element becomes part of a display:none subtree and then later becomes displayed again, the transition manager is not notified of a style change when it becomes displayed again (when we do not have the old style context). This patch introduces code to prune the finished transitions when that happens. This really fixes only part of the set of problems described in bug 1158431, which also affect running transitions. However, it's the part of that set that was a regression from bug 960465, which introduced the retention of finished transitions, and which makes these issues substantially easier to hit. I'd like to fix this part quickly because it's a regression and we should backport the fix. Without the patch, I confirmed that the following two tests fail: INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1 INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5 With the patch, all the added tests pass. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
continue;
}
dom::KeyframeEffectReadOnly* effect = anim->GetEffect();
MOZ_ASSERT(effect->Properties().Length() == 1,
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles Since bug 960465 patch 14, we've retained finished transitions in order to handle the issues described in https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The code that did this made the assumption that the transition manager is notified of the full sequence of style changes that happen to an element. However, when an element becomes part of a display:none subtree and then later becomes displayed again, the transition manager is not notified of a style change when it becomes displayed again (when we do not have the old style context). This patch introduces code to prune the finished transitions when that happens. This really fixes only part of the set of problems described in bug 1158431, which also affect running transitions. However, it's the part of that set that was a regression from bug 960465, which introduced the retention of finished transitions, and which makes these issues substantially easier to hit. I'd like to fix this part quickly because it's a regression and we should backport the fix. Without the patch, I confirmed that the following two tests fail: INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1 INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5 With the patch, all the added tests pass. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
"Should have one animation property for a transition");
MOZ_ASSERT(effect->Properties()[0].mSegments.Length() == 1,
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles Since bug 960465 patch 14, we've retained finished transitions in order to handle the issues described in https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The code that did this made the assumption that the transition manager is notified of the full sequence of style changes that happen to an element. However, when an element becomes part of a display:none subtree and then later becomes displayed again, the transition manager is not notified of a style change when it becomes displayed again (when we do not have the old style context). This patch introduces code to prune the finished transitions when that happens. This really fixes only part of the set of problems described in bug 1158431, which also affect running transitions. However, it's the part of that set that was a regression from bug 960465, which introduced the retention of finished transitions, and which makes these issues substantially easier to hit. I'd like to fix this part quickly because it's a regression and we should backport the fix. Without the patch, I confirmed that the following two tests fail: INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1 INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5 With the patch, all the added tests pass. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
"Animation property should have one segment for a transition");
const AnimationProperty& prop = effect->Properties()[0];
const AnimationPropertySegment& segment = prop.mSegments[0];
// Since effect is a finished transition, we know it didn't
// influence style.
StyleAnimationValue currentValue;
if (!ExtractComputedValueForTransition(prop.mProperty, aNewStyleContext,
currentValue) ||
currentValue != segment.mToValue) {
anim->CancelFromStyle();
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles Since bug 960465 patch 14, we've retained finished transitions in order to handle the issues described in https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The code that did this made the assumption that the transition manager is notified of the full sequence of style changes that happen to an element. However, when an element becomes part of a display:none subtree and then later becomes displayed again, the transition manager is not notified of a style change when it becomes displayed again (when we do not have the old style context). This patch introduces code to prune the finished transitions when that happens. This really fixes only part of the set of problems described in bug 1158431, which also affect running transitions. However, it's the part of that set that was a regression from bug 960465, which introduced the retention of finished transitions, and which makes these issues substantially easier to hit. I'd like to fix this part quickly because it's a regression and we should backport the fix. Without the patch, I confirmed that the following two tests fail: INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1 INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5 With the patch, all the added tests pass. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
animations.RemoveElementAt(i);
}
} while (i != 0);
if (collection->mAnimations.IsEmpty()) {
collection->Destroy();
// |collection| is now a dangling pointer!
collection = nullptr;
}
}
void
nsTransitionManager::UpdateCascadeResultsWithTransitions(
AnimationCollection* aTransitions)
{
AnimationCollection* animations = mPresContext->AnimationManager()->
GetAnimations(aTransitions->mElement,
aTransitions->PseudoElementType(), false);
UpdateCascadeResults(aTransitions, animations);
}
void
nsTransitionManager::UpdateCascadeResultsWithAnimations(
AnimationCollection* aAnimations)
{
AnimationCollection* transitions = mPresContext->TransitionManager()->
GetAnimations(aAnimations->mElement,
aAnimations->PseudoElementType(), false);
UpdateCascadeResults(transitions, aAnimations);
}
void
nsTransitionManager::UpdateCascadeResultsWithAnimationsToBeDestroyed(
const AnimationCollection* aAnimations)
{
// aAnimations is about to be destroyed. So get transitions from it,
// but then don't pass it to UpdateCascadeResults, since it has
// information that may now be incorrect.
AnimationCollection* transitions =
mPresContext->TransitionManager()->
GetAnimations(aAnimations->mElement,
aAnimations->PseudoElementType(), false);
UpdateCascadeResults(transitions, nullptr);
}
void
nsTransitionManager::UpdateCascadeResults(AnimationCollection* aTransitions,
AnimationCollection* aAnimations)
{
if (!aTransitions) {
// Nothing to do.
return;
}
nsCSSPropertySet propertiesUsed;
#ifdef DEBUG
nsCSSPropertySet propertiesWithTransitions;
#endif
// http://dev.w3.org/csswg/css-transitions/#application says that
// transitions do not apply when the same property has a CSS Animation
// on that element (even though animations are lower in the cascade).
if (aAnimations) {
TimeStamp now = mPresContext->RefreshDriver()->MostRecentRefresh();
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
aAnimations->EnsureStyleRuleFor(now);
if (aAnimations->mStyleRule) {
aAnimations->mStyleRule->AddPropertiesToSet(propertiesUsed);
}
}
// Since we should never have more than one transition for the same
// property, it doesn't matter what order we iterate the transitions.
// But let's go the same way as animations.
bool changed = false;
AnimationPtrArray& animations = aTransitions->mAnimations;
for (size_t animIdx = animations.Length(); animIdx-- != 0; ) {
MOZ_ASSERT(animations[animIdx]->GetEffect() &&
animations[animIdx]->GetEffect()->Properties().Length() == 1,
"Should have one animation property for a transition");
AnimationProperty& prop = animations[animIdx]->GetEffect()->Properties()[0];
bool newWinsInCascade = !propertiesUsed.HasProperty(prop.mProperty);
if (prop.mWinsInCascade != newWinsInCascade) {
changed = true;
}
prop.mWinsInCascade = newWinsInCascade;
// assert that we don't need to bother adding the transitioned
// properties into propertiesUsed
#ifdef DEBUG
MOZ_ASSERT(!propertiesWithTransitions.HasProperty(prop.mProperty),
"we're assuming we have only one transition per property");
propertiesWithTransitions.AddProperty(prop.mProperty);
#endif
}
Bug 1188251 part 12 - Use RestyleType::Layer in UpdateCascade; r=dholbert When updating the cascade results between transitions and animations, if we detect a change we force an update by taking the following steps: a. Updating the animation generation on the restyle manager b. Updating the animation generation on the collection c. Iterating over all the properties animated by the collection and, for each property that we can animate on the compositor, posting a restyle event with the appropriate change hint (nsChangeHint_UpdateTransformLayer or nsChangeHint_UpdateTransformOpacity) d. Marking the collection as needing refreshes e. Clearing the style rule refresh time so we generate a new style rule in EnsureStyleRuleFor As it turns out, the newly-added AnimationCollection::RequestRestyle(RestyleType::Layer) already performs a, b, d, and e. It also: * Ensures we are observing the refresh driver if need be (should have no effect in this case) * Clears the last animation style update time on the pres context so that subsequent calls to FlushPendingNotifications will update animation style (it seems like we probably should have been doing this for changes to cascade results anyway) * Posts a restyle event with restyle hint eRestyle_CSSTransitions or eRestyle_CSSAnimations * Marks the document as needing a style flush (irrelevant since posting a restyle event does this anyway) The only missing piece that would prevent using RequestRestyle in place of this code when updating cascade results is (c) from the list above. However, (c) should not be necessary since ElementRestyler::AddLayerChangesForAnimation() explicitly checks for out-of-date layer animation generation numbers and adds the appropriate change hints (nsChangeHint_UpdateTransformLayer etc.) to the change list.
2015-08-18 10:11:55 +03:00
// If there is any change in the cascade result, update animations on layers
// with the winning animations.
if (changed) {
Bug 1188251 part 12 - Use RestyleType::Layer in UpdateCascade; r=dholbert When updating the cascade results between transitions and animations, if we detect a change we force an update by taking the following steps: a. Updating the animation generation on the restyle manager b. Updating the animation generation on the collection c. Iterating over all the properties animated by the collection and, for each property that we can animate on the compositor, posting a restyle event with the appropriate change hint (nsChangeHint_UpdateTransformLayer or nsChangeHint_UpdateTransformOpacity) d. Marking the collection as needing refreshes e. Clearing the style rule refresh time so we generate a new style rule in EnsureStyleRuleFor As it turns out, the newly-added AnimationCollection::RequestRestyle(RestyleType::Layer) already performs a, b, d, and e. It also: * Ensures we are observing the refresh driver if need be (should have no effect in this case) * Clears the last animation style update time on the pres context so that subsequent calls to FlushPendingNotifications will update animation style (it seems like we probably should have been doing this for changes to cascade results anyway) * Posts a restyle event with restyle hint eRestyle_CSSTransitions or eRestyle_CSSAnimations * Marks the document as needing a style flush (irrelevant since posting a restyle event does this anyway) The only missing piece that would prevent using RequestRestyle in place of this code when updating cascade results is (c) from the list above. However, (c) should not be necessary since ElementRestyler::AddLayerChangesForAnimation() explicitly checks for out-of-date layer animation generation numbers and adds the appropriate change hints (nsChangeHint_UpdateTransformLayer etc.) to the change list.
2015-08-18 10:11:55 +03:00
aTransitions->RequestRestyle(AnimationCollection::RestyleType::Layer);
}
}
/*
* nsIStyleRuleProcessor implementation
*/
/* virtual */ size_t
nsTransitionManager::SizeOfExcludingThis(MallocSizeOf aMallocSizeOf) const
{
return CommonAnimationManager::SizeOfExcludingThis(aMallocSizeOf);
// Measurement of the following members may be added later if DMD finds it is
// worthwhile:
// - mEventDispatcher
}
/* virtual */ size_t
nsTransitionManager::SizeOfIncludingThis(MallocSizeOf aMallocSizeOf) const
{
return aMallocSizeOf(this) + SizeOfExcludingThis(aMallocSizeOf);
}