Having MotionPathData in layers::Animation is a bit inefficient for animations
other than transform like properties.
Differential Revision: https://phabricator.services.mozilla.com/D65921
--HG--
extra : moz-landing-system : lando
So we don't need to create motion path data if there is no offset-path style
and no animations of offset-path.
Differential Revision: https://phabricator.services.mozilla.com/D57907
--HG--
extra : moz-landing-system : lando
The benefits are:
1. For the rest `layers::Animation`s, their `TransformData` are `Nothing()`,
so we can avoid any posisible copy.
2. In the compositor, we move `TransformData` out of the array, and use
`UniquePtr` to avoid including AnimationHelper.h into AnimationInfo.h,
which causes some compilation errors because LayersMessages.h is not
visible in AnimationInfo.h.
Differential Revision: https://phabricator.services.mozilla.com/D57751
--HG--
extra : moz-landing-system : lando
We cache the path in AnimationInfo for layers, and in
CompsoitorAnimationStorage for web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50013
--HG--
extra : moz-landing-system : lando
It allows for use of default constructor/destructor and leaves no room to incorrectly modify the union members with a wrong type.
Differential Revision: https://phabricator.services.mozilla.com/D26061
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
On the sender side of transactions, we have to convert the individual transforms
to the proper types in layers::Animations, and this includes SetAnimatable and
the definition in LayersMessages.
On the compositor side (i.e. received side of transactions). Basically, we
convert the list of layers::Animation into a list of `PropertyAnimationGroup`,
which is an intermediate value. And then use this list to do interpolation for
each property in `SampleAnimationForEachNode`, which will return a list of
`RefPtr<RawServoAnimationValue>`.
Depends on D23062
Differential Revision: https://phabricator.services.mozilla.com/D22565
--HG--
extra : moz-landing-system : lando
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
Both layers and web-render use this function, so we factor it out.
Depends on D22562
Differential Revision: https://phabricator.services.mozilla.com/D22563
--HG--
extra : moz-landing-system : lando
On the compositor we store animation values in a hash table and the hash is
the compositor animation id which is a unique id for each property respectively.
So we can get the corresponding animation value for the given property.
In this patch there are lots of duplicated code, but they will be removed in the
next patch.
MozReview-Commit-ID: 7EboVcculcg
--HG--
extra : rebase_source : 304ea80849af8af72a07437736041aeabbe47eeb
On the compositor we store animation values in a hash table and the hash is
the compositor animation id which is a unique id for each property respectively.
So we can get the corresponding animation value for the given property.
In this patch there are lots of duplicated code, but they will be removed in the
next patch.
MozReview-Commit-ID: 7EboVcculcg
--HG--
extra : rebase_source : 304ea80849af8af72a07437736041aeabbe47eeb
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
If the animation is in delay phase, we shouldn't produce any values for the
animation but we have to make sure subsequent ticks happen in order to the time
when the animation starts. So what we should do here is that
1) Make AnimationHelper::SampleAnimations() return boolean, return true if
there is any animation.
2) Schedule the next tick if AnimationHelper::SampleAnimations return true
This setup is equivalent to what we do non-WebRender.
So that we don't need to set non-animated value as AnimatedValue for delay
phase to make subsequent ticks happen for the delay phase animations. The
non-animated value will be dropped in the next patch.
MozReview-Commit-ID: IwltLGgvT7K
--HG--
extra : rebase_source : f2c59cb3bdb3affc5846e65ccbaad7dbc069d0ad
When we send play-pending animation to the compositor, we resolve its start
time with the time at the very moment we send the animation to the compositor
instead of refresh drivers' tick time. That means that it's possible that the
start time indicates more future time stamp than the previous frame time stamp
on the compositor. If we were to use the previous frame timestamp in this
case, then we'd end up treating the animation as if it had not yet started so
we would skip its initial paint.
MozReview-Commit-ID: 8TdZ6m0gqMm
--HG--
extra : rebase_source : ce712308ef9ef24dcef2c39a89bb5935e305a09c
So that we can do an additional check depending on each animation in a subsequent
patch in this patch series.
MozReview-Commit-ID: C1ZJMdwraVk
--HG--
extra : rebase_source : baa71d25e45fbc1db20312788251bcced692b6cf
If the animation is in delay phase, we shouldn't produce any values for the
animation but we have to make sure subsequent ticks happen in order to the time
when the animation starts. So what we should do here is that
1) Make AnimationHelper::SampleAnimations() return boolean, return true if
there is any animation.
2) Schedule the next tick if AnimationHelper::SampleAnimations return true
This setup is equivalent to what we do non-WebRender.
So that we don't need to set non-animated value as AnimatedValue for delay
phase to make subsequent ticks happen for the delay phase animations. The
non-animated value will be dropped in the next patch.
MozReview-Commit-ID: IwltLGgvT7K
--HG--
extra : rebase_source : 9854b182134adf3060260849741142841721d65b
Note that we have to calculate animation values if there is another animation
since the other animation might be 'accumulate' or 'add', or might have a
missing keyframe (i.e. the calculated animation values will be used in the
missing keyframe).
MozReview-Commit-ID: rQyS9nuVJi
--HG--
extra : rebase_source : 6ddc70308e223a709eba9c4c2f05e42bbc0f3160
We don't need to calculate TimingParams each time we compose an animation on
the compositor because TimingParams is immobile since the animation was sent to
the compositor.
MozReview-Commit-ID: 3rfzkdGClES
--HG--
extra : rebase_source : e28650a30b1cbd14789688f2acc03d204069e2fb
Two AnimationValue are still used in AnimationPropertySegment since the
AnimationPropertySegment is used in compose_animation_segment() which is also
invoked on the main-thread, so we will fix it later in a bug that will drop
AnimationValue usage on the main-thread side.
MozReview-Commit-ID: B086g2qHtZL
--HG--
extra : rebase_source : 419308155bf95fb0acd94549c2c6cc9690925b29
This is slightly efficient since we don't need to call
GetBaseAnimationStyle() or we do skip allocating animation data for such case.
MozReview-Commit-ID: BYFNwZsZ1oE
--HG--
extra : rebase_source : 441d7431bd444f1513a32d4da3c206c7df34ed94
Need to pass the default transform/opacity to compositor if animations
exist because it is possible that gecko fails to get animated value
after animation sampling, like an animation with delay.
MozReview-Commit-ID: IK06hWvaSPf
Hiroyuki Ikezoe
Boris Chiou
Jean-Yves Avenard
Alex Gaynor
Doug Thayer
Ciure Andrei
Sylvestre Ledru
Hiroyuki Ikezoe
Andreea Pavel
Andi-Bogdan Postelnicu
Coroiu Cristina
Emilio Cobos Álvarez
Dorel Luca
Sebastian Hengst
Tristan Bourvon
Kartikaya Gupta
sotaro
peter chang