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
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
