We fail to animate opacity in WK1 because we make the assumption that just because an animation targets only accelerated properties it will be accelerated and won't need to be updated as it runs in WebAnimation::timeToNextTick(). This is incorrect, an animation may fail to start or may fail to get a composited layer, the latter being the case on WK1 because usesCompositing() is false in RenderLayerCompositor::requiresCompositingForAnimation().
<rdar://problem/59061225>
Created attachment 389353 [details] Patch
Comment on attachment 389353 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=389353&action=review > Source/WebCore/animation/WebAnimation.cpp:1448 > + if (!isCompletelyAccelerated() || !isRunningAccelerated()) This would be clearers as hasAnyNonAcceleratedProperties or something, I think. > LayoutTests/webanimations/opacity-animation.html:15 > + setTimeout(() => testRunner.notifyDone(), 100); 100ms is a really long test. Would setting the current time and pausing test the same way? Why didn't requestAnimationFrame work?
(In reply to Simon Fraser (smfr) from comment #3) > Comment on attachment 389353 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=389353&action=review > > > Source/WebCore/animation/WebAnimation.cpp:1448 > > + if (!isCompletelyAccelerated() || !isRunningAccelerated()) > > This would be clearers as hasAnyNonAcceleratedProperties or something, I > think. I'll switch the code around to have a condition that starts with `if (isCompletelyAccelerated() && isRunningAccelerated())` instead. This covers the case of animations that don't need to be updated while running. > > LayoutTests/webanimations/opacity-animation.html:15 > > + setTimeout(() => testRunner.notifyDone(), 100); > > 100ms is a really long test. Would setting the current time and pausing test > the same way? Alas, no, because at that point it would no longer be running an accelerated animation, which is precisely what we're trying to test. > Why didn't requestAnimationFrame work? Alas, I'm not sure. I'll try to improve this in bug 207054.
Committed r255504: <https://trac.webkit.org/changeset/255504>