本文整理汇总了C++中KeyframeEffectReadOnly::ComposeStyle方法的典型用法代码示例。如果您正苦于以下问题:C++ KeyframeEffectReadOnly::ComposeStyle方法的具体用法?C++ KeyframeEffectReadOnly::ComposeStyle怎么用?C++ KeyframeEffectReadOnly::ComposeStyle使用的例子?那么, 这里精选的方法代码示例或许可以为您提供帮助。您也可以进一步了解该方法所在类KeyframeEffectReadOnly
的用法示例。
在下文中一共展示了KeyframeEffectReadOnly::ComposeStyle方法的1个代码示例,这些例子默认根据受欢迎程度排序。您可以为喜欢或者感觉有用的代码点赞,您的评价将有助于系统推荐出更棒的C++代码示例。
示例1: PlayState
void
Animation::ComposeStyle(RefPtr<AnimValuesStyleRule>& aStyleRule,
nsCSSPropertyIDSet& aSetProperties)
{
if (!mEffect) {
return;
}
if (!IsInEffect()) {
return;
}
// In order to prevent flicker, there are a few cases where we want to use
// a different time for rendering that would otherwise be returned by
// GetCurrentTime. These are:
//
// (a) For animations that are pausing but which are still running on the
// compositor. In this case we send a layer transaction that removes the
// animation but which also contains the animation values calculated on
// the main thread. To prevent flicker when this occurs we want to ensure
// the timeline time used to calculate the main thread animation values
// does not lag far behind the time used on the compositor. Ideally we
// would like to use the "animation ready time" calculated at the end of
// the layer transaction as the timeline time but it will be too late to
// update the style rule at that point so instead we just use the current
// wallclock time.
//
// (b) For animations that are pausing that we have already taken off the
// compositor. In this case we record a pending ready time but we don't
// apply it until the next tick. However, while waiting for the next tick,
// we should still use the pending ready time as the timeline time. If we
// use the regular timeline time the animation may appear jump backwards
// if the main thread's timeline time lags behind the compositor.
//
// (c) For animations that are play-pending due to an aborted pause operation
// (i.e. a pause operation that was interrupted before we entered the
// paused state). When we cancel a pending pause we might momentarily take
// the animation off the compositor, only to re-add it moments later. In
// that case the compositor might have been ahead of the main thread so we
// should use the current wallclock time to ensure the animation doesn't
// temporarily jump backwards.
//
// To address each of these cases we temporarily tweak the hold time
// immediately before updating the style rule and then restore it immediately
// afterwards. This is purely to prevent visual flicker. Other behavior
// such as dispatching events continues to rely on the regular timeline time.
AnimationPlayState playState = PlayState();
{
AutoRestore<Nullable<TimeDuration>> restoreHoldTime(mHoldTime);
if (playState == AnimationPlayState::Pending &&
mHoldTime.IsNull() &&
!mStartTime.IsNull()) {
Nullable<TimeDuration> timeToUse = mPendingReadyTime;
if (timeToUse.IsNull() &&
mTimeline &&
mTimeline->TracksWallclockTime()) {
timeToUse = mTimeline->ToTimelineTime(TimeStamp::Now());
}
if (!timeToUse.IsNull()) {
mHoldTime.SetValue((timeToUse.Value() - mStartTime.Value())
.MultDouble(mPlaybackRate));
}
}
KeyframeEffectReadOnly* keyframeEffect = mEffect->AsKeyframeEffect();
if (keyframeEffect) {
keyframeEffect->ComposeStyle(aStyleRule, aSetProperties);
}
}
MOZ_ASSERT(playState == PlayState(),
"Play state should not change during the course of compositing");
mFinishedAtLastComposeStyle = (playState == AnimationPlayState::Finished);
}