Commit Graph

8 Commits

Author SHA1 Message Date
Brian Birtles
bf0b758990 Bug 1229280 - Move animation generation from AnimationCollection to EffectSet; r=dbaron
--HG--
extra : rebase_source : 26a942c8c6058e629e7d7ed549eb1fcdf7f6d399
2016-01-06 11:04:05 +09:00
Brian Birtles
c773cf7551 Bug 1228229 part 4 - Add a flag to EffectSet to mark when the cascade needs to be updated; r=dbaron
There are three situations when the cascade results of effects needs to be
updated.

1. The sets of effects (animations) has changed.

2. One or more effects have changed their "in effect" status.

3. Other style properties affecting the element have changing meaning that
   animations applied at the animations-level of the cascade may now be
   overridden or become active again.

We want to detect these situations so we can avoid updating the cascade when
none of these possibilities exist.

Currently we handle case 1 by calling UpdateCascadeResults at the appropriate
point in nsAnimationManager and nsTransitionManager when we build
animations/transtiions.

Case 2 only affects animations (since whether transitions are in effect or not
makes no difference to the cascade--they have a lower "composite order" than
animations and never overlap with each other so they can't override anything).
As a result, we handle it by adding a flag to CSSAnimation to track when an
animation was in effect last time we checked or not.

For case 3, we take care to call UpdateCascadeResults when the style context
changed in nsAnimationManager::CheckAnimationRule (called from
nsStyleSet::GetContext).

We want to generalize this detection to handle script-generated animations too.
In order to do that this patch introduces a flag to EffectSet that we will use
to mark when the cascade needs to be updated in cases 1 and 2. This patch also
sets the flag when we detect case 1. A subsequent patch sets the flag for
case 2.

Case 3 is more difficult to detect and so we simply maintain the existing
behavior of making nsAnimationManager::CheckAnimationRule unconditionally
update the cascade without checking if the "needs update" flag is set.

--HG--
extra : rebase_source : fc56b1bb5a98ae78b93a179c7a3b8af4724a06a1
2016-01-06 11:04:04 +09:00
Brian Birtles
c70be15294 Bug 1230056 part 1 - Add EffectCompositor::HasAnimationsForCompositor; r=dholbert 2015-12-09 16:28:10 -05:00
Brian Birtles
5ea3caedb7 Bug 1226118 part 1 - Add EffectSet::GetEffectSet(const nsIFrame*); r=dholbert 2015-12-04 08:32:52 +09:00
Brian Birtles
4a1f1632e9 Bug 1225699 part 6 - Use strong refs to store effects on their target elements; r=smaug
This is so that when we have code like:

  elem.animate({ opacity: 0 }, 1000)

the resulting Animation object is kept alive by |elem| based on the following
ownership chain:

  elem --(strong)--> KeyframeEffectReadOnly --(strong)--> Animation

Now, there is an ownership cycle introduced here because KeyframeEffectReadOnly
objects also store owning references to their target elements. This is broken
when the Animation finishes (if it does not fill forwards) or is cancelled
since either event will trigger a call to
KeyframeEffectReadOnly::UpdateTargetRegistration.

If the Animation fills forwards, the resource will not be released until
it is cancelled. For Animations corresponding to CSS Animations / CSS
Transitions this happens when the Element is unbound or when the corresponding
style property is updated causing the animation to be replaced or removed.

For the general case of script-generated animations, however, this cycle won't
be broken until the Element is unbound and all external references to the
Animation or KeyframeEffectReadOnly are dropped.

It's unfortunate that we can't more aggressively prune these objects but it's
what the spec currently says. I've posted to the mailing list[1] about this but
have yet to find a good solution.

[1] https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0029.html
2015-11-26 16:53:54 +09:00
Brian Birtles
0d264e1081 Bug 1225699 part 4 - Add iterator to EffectSet; r=heycam 2015-11-26 16:53:53 +09:00
Brian Birtles
ac5c423799 Bug 1225699 part 2 - Add Add/RemoveEffect to EffectSet; r=smaug 2015-11-26 16:53:53 +09:00
Brian Birtles
9400c59793 Bug 1225699 part 1 - Add EffectSet class; r=smaug 2015-11-26 16:53:53 +09:00