Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 24fe4db710ae0a219b161d854249fe24e5d64f51
https://github.com/WebKit/WebKit/commit/24fe4db710ae0a219b161d854249fe24e5d64f51
Author: Antoine Quint <[email protected]>
Date: 2026-02-10 (Tue, 10 Feb 2026)
Changed paths:
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
Log Message:
-----------
[threaded-animations] multiple View Transitions tests crash with "Threaded
Time-based Animations" enabled
https://bugs.webkit.org/show_bug.cgi?id=307446
rdar://170065802
Reviewed by Simon Fraser.
There are two distinct methods to query a keyframe effect about its
acceleration state:
- `KeyframeEffect::isAboutToRunAccelerated()` indicates that the animation
qualifies for acceleration
but is pending processing.
- `KeyframeEffect::isRunningAccelerated()` indicates that the animation has
been processed and is actively
running with acceleration.
We had an implementation of the latter that accounted for threaded animations,
but not for the former.
In `KeyframeEffect::isRunningAccelerated()` we returned true as long as an
animation could be accelerated
as a threaded animation and was running (and not suspended), but we neglected
to account for the possibility
that it had not actually been accelerated inside of
`RenderLayerBacking::updateAcceleratedEffectsAndBaseValues()`.
This had some bad implications in the case of View Transitions where a simple
navigation between two pages with
`navigation: auto` will yield a set of layers like so:
::view-transition-group (animates width / height / transform /
backdrop-filter)
+- ::view-transition-old (animates opacity)
+- ::view-transition-new (animates opacity)
The two child layers will have their animations accelerated because of the
simple opacity animation. Meanwhile,
the parent `::view-transition-group` may not since `transform` may not be
accelerated if width and height are
also accelerated and it contains a relative unit.
In the soon-to-be legacy codebase for accelerated animations, we tracked
whether an animation was rejected for
acceleration during processing with `enum RunningAccelerated { NotStarted, Yes,
Prevented, Failed }`, and
`isRunningAccelerated()` would only return true in the case of
`RunningAccelerated::Yes`. This matters because
`RenderLayerCompositor::computeCompositingRequirements()` has an assertion that
ensures compositing-related
state did not change without the compositor being told, and in that assertion
`needsToBeComposited()` would
return `true` because our incorrect implementation of `isRunningAccelerated()`
indicated so.
We address this by correctly implementing the two methods introduced above. Now:
- `KeyframeEffect::isAboutToRunAccelerated()` has awareness of threaded
animations and will return true
only if it does not have an accelerated representation, since its mere
existence indicates that it
has been processed and is not longer pending.
- `KeyframeEffect::isRunningAccelerated()` correctly checks whether the
accelerated representation has
been processed by only returning true if it has an accelerated representation
that has animated
properties.
Note that there is no test change in this patch since the flag is not yet
enabled on bots. This
was caught in preparation of that running animation tests locally using
`--experimental-feature ThreadedTimeBasedAnimationsEnabled=true`.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::isRunningAccountingForSuspension const):
(WebCore::KeyframeEffect::isRunningAccelerated const):
(WebCore::KeyframeEffect::isAboutToRunAccelerated const):
* Source/WebCore/animation/KeyframeEffect.h:
Canonical link: https://commits.webkit.org/307197@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
