An earlier patch for this bug (changeset 466d3ff030e6) removed local variable
"nsRect area", but then ended up effectively re-creating it further down in the
function as "contentBoxRect". (I added contentBoxRect as a late-breaking
change, as part of addressing a review comment.)
I've now realized that contentBoxRect is the same rect as "area", and it's
simpler to just declare the original "area" rect at the function's start
instead of dynamically creating it further down.
(Not requesting review, since this is a no-functional-change tweak, which is
following up on a change that I'd made in response to review feedback on a r+'d
patch.)
Now that there is a public accessor for mStartTime, we can make it a protected
member of AnimationPlayer. The only time mStartTime is ever set is when playing
the animation so we can replace external modifications to mStartTime with calls
to Play(). This simplifies implementing deferred starting of animations
in bug 927349 by isolating the deferred playback logic to AnimationPlayer.
Note that even when we call PauseFromStyle immediately afterwards we still need
to call PlayFromStyle (or Play) first in order to resolve the time at which the
player should be paused. A newly created player doesn't have a current time so
if we were simply to call pause it wouldn't pause at the start of the animation
as we might expect. The call to Play(FromStyle) will cause the current time to
become zero and then we pause at that time.
This makes the color matrix and component transfer Moz2D filters generate an infinite output, which is then cropped to the primitive's filter primitive subregion by a subsequent crop filter node. This still gives us different behavior than other browser when the primitive subregion is overridden using the x/y/width/height attributes - other browsers either ignore those completely (IE) or only let them crop the default subregion (which is defined to be the same as the input subregion) and not enlargen it - but I'll fix that in a separate bug.
This depends on bug 1086937 patch 1 because it requires that
ResolveStyleWithReplacement support eRestyle_ChangeAnimationPhase on
::before and ::after pseudo-elements.
It also depends on patch 1 of this bug for the reasons described in
patch 1's commit message.
This is needed for bug 960465 so that we can use these hints to detect
whether pending restyles include restyles other than those for
animations. In other words, patches for bug 960465 (or perhaps a
dependent bug that lands before it) will require that all animation
restyles use an animation-specific nsRestyleHint.
It is also, on its own, a performance improvement for animations and
transitions, since we will stop rerunning selector matching on the
animating element during the progress of the animations or transitions.
Once we remove eRestyle_ChangeAnimationPhase the performance improvement
will even become slightly better.
Note that the eRestyle_ChangeAnimationPhase is needed in some cases
because we use PostRestyleForAnimation in the non-animation-restyle
phase when we have a style rule that we need to add during the animation
restyle phase. (It's not needed during the progress of the animation,
though. But hopefully both eRestyle_ChangeAnimationPhase will go away
soon, after bug 960465. And hopefully the way we tick animations will
also change to look more like the animation-only restyle, but without
the main-thread-suppressed (throttled) animations.)
I confirmed that this assertion fires (along with the other failures)
when running layout/style/test/test_transitions_events.html with patch 3
but not patch 1.
Without this patch, patch 3 will cause bugs where we'll never remove the
cover rule we create during the process of starting a transition. This
won't actually be problematic during the transition, since the
transition will overwrite it, but once the transition completes, the
cover rule will still be around, and we'll be stuck with the
pre-transition value instead of the post-transition value.
It's possible it also fixes existing bugs prior to the patch series in
this bug.
The existing relationship between the particular versions of
AnimationPlayer::Play* (particularly in the CSSAnimationPlayer) subclass are
confusing because, for example, CSSAnimationPlayer::PlayFromStyle needs to be
careful to *not* call Play on CSSAnimationPlayer, but only on the parent
object (since otherwise we reset the sticky pause behavior).
This patch reworks this relationship by adding a protected DoPlay method that
performs the common pausing behavior. Play/PlayFromJS/PlayFromStyle then add
flushing, sticky pausing etc. as necessary.
This patch also removes the UpdateFlags enum and parameters previously used to
control whether we forced an update to style. This is no longer necessary since
we no longer call 'Play' from style. Instead we make Play always post restyles.
If we come across a case where we want to call Play and *not* post restyles, we
can re-add the flags then.
Roughly the same arrangement is true for Pause except that we don't currently
flush styles for CSS animations in PauseFromJS since it currently won't make any
observable difference.
We often set mStyleRuleRefreshTime to null to ensure styles get updated.
However, CanThrottleTransformChanges doesn't check for this case and blindly
does subtraction using this value.
Until now we've got away with this but now that we set mStyleRuleRefreshTime to
null when making changes via the API this case crops up in different
circumstances and we can trip over it.
This patch simply adds a null check before using mStyleRuleRefreshTime in
CanThrottleTransformChanges. All other cases where we operate on
mStyleRuleRefreshTime check for null.
For some kinds of changes we need to update the layer tree even though there is
no change to style. For example, if an animation is paused via the Web
Animations API, we need to remove the animation from the layer even though the
style will not change.
This patch detects such changes by making ElementRestyler check for an
out-of-date animation generation on layers. This is complicated by the fact that
we currently maintain *two* animation generation numbers: one for the set of
animations and one for the set of transitions, but we only have *one* animation
generation number on each layer. This is a known issue (bug 847286).
As a result, until bug 847286 is fixed, we need to be careful to compare against
the greater of the two numbers.
nsAnimationManager provides GetAnimationPlayers while nsTransitionManager
provides GetElementTransitions. Both perform the same function, namely, fetching
(and optionally creating if it does not exist) the AnimationPlayerCollection for
the specified element/pseudo. Furthermore, both take the same arguments.
This patch aligns the method names and makes this a virtual method on the base
class CommonAnimationManager so that it can be used generically from a pointer
to a CommonAnimationManager.
This patch introduces an abstract method to AnimationPlayer to fetch the manager
object associated with the player. This method is implemented separate by
CSSAnimationPlayer and CSSTransitionPlayer to return the nsAnimationManager or
nsTransitionManager accordingly.
Previously AnimationPlayer::Play() and AnimationPlayer::PlayState() would flush
styles as part of their operation. This, however, is only needed when the player
corresponds to a CSS Animation or CSS Transition. Now that we have concrete
subclasses for each of these cases we can move style flushing to the subclasses
and remove it from the base class (which is expected to be shared with
animations that are not dependent on style).
In order to be able to find the collection a player belongs to from its source
content, we first need to be able to determine which manager--the animation
manager or transition manager--to look up.
We eventually plan to push transition event dispatch down to a CSS
transitions-specific subclass of AnimationPlayer, so this seems like a suitable
point to introduce this class.
Using this subclass we can define a virtual GetManager method that will
return the appropriate animation/transition manager for the player.
Now that CheckNeedsRefresh is a member of the base class,
CommonAnimationManager, we no longer need to rely on callers of
AnimationPlayerCollection::EnsureStyleRuleFor to remember to call this method
but can do it automatically.
In order to add AnimationPlayerCollection::NotifyPlayerUpdated, collections
need a way of updating their managers to inform them that their mNeedsRefreshes
flag has changed and hence the manager may need to resume observing the refresh
driver.
Currently, only nsAnimationManager makes use of mNeedsRefreshes and provides
a CheckNeedsRefresh method. In order to allow AnimationPlayerCollection to
operate independently of the type of manager it is attached to (and because
there's a lot of similar code here that we eventually want to move to a common
manager anyway), this patch moves CheckNeedsRefreshes and associated
machinery to CommonAnimationManager.
DrawTargets that support region clipping are able to clip to regions effectively. Other DrawTargets go through expensive complex clip paths. When invalidating regions we have code that draws in multiple steps when using Direct2D to avoid this expense, we should base the decision to do this simply on whether the DrawTarget supports fast region clipping.
When SelectionCarets::Terminate() is called, it's not guaranteed that we
can get nsDocShell from PresContext. It causes that SelectionCarets
cannot remove itself as an observer.
To fix this, we keep a member WeakPtr<nsDocShell> so that we can always
have nsDocShell in SelectionCarets::Terminate().
Until we get rid of animation phases in bug 960465, we need to ensure
we're producing style data for the correct animation phase. This makes
this optimization slightly less beneficial until then.
This makes APZ behave nicely with most uses of a css transform:scale.
Summary of changes:
- FrameMetrics::mCumulativeResolution now includes the css-driven resolution
in addition to the pres-shell resolution.
- Displayports are now stored in Screen pixels rather than Layer pixels.
This is what we want anyways (as we'd like the displayport size to remain
constant as a fraction of the screen size), but it was necessary to make
this change as part of this patch because continuing to store them in
Layer pixels in the presence of a css-driven resolution would have
required a bunch of infrastructure to implement correctly.
Remaining work:
- Layout painting a scrollable layer at a resolution different from the
scale induced by the css transform causes problems. These will go away
with bug 1076192.
- Different resolutions on the x and y axes are not supported. This is
tracked by bug 1039967.
This makes APZ behave nicely with most uses of a css transform:scale.
Summary of changes:
- FrameMetrics::mCumulativeResolution now includes the css-driven resolution
in addition to the pres-shell resolution.
- Displayports are now stored in Screen pixels rather than Layer pixels.
This is what we want anyways (as we'd like the displayport size to remain
constant as a fraction of the screen size), but it was necessary to make
this change as part of this patch because continuing to store them in
Layer pixels in the presence of a css-driven resolution would have
required a bunch of infrastructure to implement correctly.
Remaining work:
- Layout painting a scrollable layer at a resolution different from the
scale induced by the css transform causes problems. These will go away
with bug 1076192.
- Different resolutions on the x and y axes are not supported. This is
tracked by bug 1039967.
By not excluding opaque borders from the display item cliprects, we produce
a larger opaque area for opaque background items.
--HG--
extra : rebase_source : 4e27157c2b60d1a0386a4db681dd8f1e741b61fd
