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
Before this change, the value which was set by SetShadowBaseTransform()
has been used for the assertion, but it is possible that the value is changed
by APZ. And it's hard to tell whether the value has been changed by APZ or not
and it's hard to *reverse-calculate* the differences in the past APZ at the
moment we want to do the assert.
So after this patch, on debug build we don't actually skip the calculation for
unchanged animations and use the newly calculated value for the assertion.
MozReview-Commit-ID: 8fCcvvbUMHe
--HG--
extra : rebase_source : 0ff5e7100ad33a690bb0edd02af2b00c749afbbe
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
We need to allocate new AnimatedValue only if there is no AnimatedValue
corresponding to the id in the hashtable.
MozReview-Commit-ID: HeRt74Tnojt
--HG--
extra : rebase_source : 6920ac7fe770e928883e9995469e972799b3c02e
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
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
Summary:
I can propagate the error up if needed, but looks like the code should cope with
it just fine with this change.
Reviewers: kats
Bug #: 1446108
Differential Revision: https://phabricator.services.mozilla.com/D794
MozReview-Commit-ID: Dm6EKIC6F5i
We want to always use Servo animation backend on the compositor.
However, Android doesn't support Stylo now, so add a defined flag for it.
MozReview-Commit-ID: 63MnTBnq6yv
--HG--
extra : rebase_source : dce46737f81e4e217e9fd67b6bec722994dca6a2
Use the new added FFI, Servo_ComposeAnimationSegment, to compose an
animation segment from Servo backend on the compositor.
MozReview-Commit-ID: LNgpCSIlDl9
--HG--
extra : rebase_source : 5b5c145fae877b4f4b01ea54259737dc9dad2951
We will use Servo backend on the compositor, so implement this for opacity.
MozReview-Commit-ID: BeWR2nBSbjb
--HG--
extra : rebase_source : eb5db3cf04640a83f13857984e792a949f26bcc7
We get the progress as |double|, and then pass it to a function by a |float|
type, and then finally cast it back to |double| for the interpolation.
We should avoid casting it back and forth, so change the function argument to
use |double| type for the progress.
MozReview-Commit-ID: 7QzfVBC7hSt
--HG--
extra : rebase_source : 62467bf0a734b650f524af656658cdfdabca2a5c
We are seeing occasional failed release assertions from calling
animation.startTime().get_TimeDuration() in SampleAnimationForEachNode on
Windows.
My theory is that in some circumstances (perhaps graphic-driver related?) when
creating a layer transaction we fail to call Layer::StartPendingAnimations and
end up sending pending animations to the compositor. Prior to bug 1334583 that
would have only triggered a debug assertion so it may have gone unnoticed if it
depends on the system configuration.
This patch makes us check that the startTime is set before we try to access it
in order to avoid triggering a release-time assertion. If the startTime is not
set we will use the hold time which should give us the correct behavior for
a still-pending animation. (Furthermore, the holdTime is set unconditionally
when we create animations so it should be correct -- but even if it were not
set explicitly, its initial zero value would still likely produce a reasonable
result until the start time was updated on a subsequent layer transaction. At
very least, it should not crash. Likewise, if it was set to an incorrect value.)
This patch also strengthens the debug assertion in SampleAnimationForEachNode to
check that not only is start time not-null, but that it is set to a TimeDuration
since MaybeTimeDuration also includes a third uninitialized "None" state.
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
By passing the startTime as a TimeDuration we are able to represent times in the
distant past (and with the same range as we can represent on the main thread so
that if we do encounter range errors in future, they should not differ between
the main thread and the compositor).
This patch includes a crashtest. I have verified that, without the code changes
included in this patch, this crashtest fails on debug builds on OSX.
MozReview-Commit-ID: EDuKLzfEC0K
--HG--
extra : rebase_source : 1883080fdfac8c33f70698145f21e67cbdfdd4f2
Hiroyuki Ikezoe
Dorel Luca
Boris Zbarsky
Xidorn Quan
Emilio Cobos Álvarez
Brindusan Cristian
Cameron McCormack
Boris Chiou
Kartikaya Gupta
Brian Birtles
peter chang