haikuwebkit/LayoutTests/webanimations/opacity-animation-no-longer...

2 lines
1 B
Raw Permalink Normal View History

Source/WebCore: [Web Animations] Perform accelerated animations when possible https://bugs.webkit.org/show_bug.cgi?id=179973 <rdar://problem/34953922> Reviewed by Dean Jackson. When we're entering and leaving the active duration of an animation effect, we now check whether the animation can be accelerated, using the existing CSSPropertyAnimation::animationOfPropertyIsAccelerated() utility, and start and stop animations using the startAnimation() and animationFinished() functions on RenderBoxModelObject. This patch is only a first step towards full support for accelerated animations, there are two known issues at the moment. Because we're not blending the styles to perform the animation, getComputedStyle() will not return the animated value (webkit.org/b/179974). Additionally, if other animations happen to run later during the active state of an animation that can run accelerated, we will not fall back to software-only animation for this element and these animations will appear not to run (webkit.org/b/179975). These will be addressed in follow-up patches. Tests: webanimations/left-and-opacity-animation-yields-no-compositing.html webanimations/opacity-animation-no-longer-composited-upon-completion.html webanimations/opacity-animation-yields-compositing.html webanimations/width-and-opacity-separate-animation-yields-no-compositing.html * animation/DocumentTimeline.cpp: (WebCore::DocumentTimeline::updateAnimations): Check in the map of pending accelerated animations to see if any animation requires toggling their active state after their styles have been invalidated. (WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange): New function to let animations indicate that they need to have their accelerated backing animation toggled after style invalidation has been completed. (WebCore::DocumentTimeline::runningAnimationsForElementAreAllAccelerated): This function is used in RenderLayerCompositor::requiresCompositingForAnimation() to identify whether an element requires hardware compositing due to running accelerated animations. We check all running animations for the provided element to see if they can all be running accelerated and return true in this situation only. * animation/DocumentTimeline.h: * animation/KeyframeEffect.cpp: (WebCore::KeyframeEffect::applyAtLocalTime): Identify if we're crossing into or out of the active state for an animation and check if it will be or has been running accelerated such that we can notify the DocumentTimeline, through the associated animation, that the accelerated backing animation will need to be toggled after style invalidation has been completed. (WebCore::KeyframeEffect::shouldRunAccelerated): Check that all properties for this animation effect can be accelerated according to CSSPropertyAnimation::animationOfPropertyIsAccelerated(). (WebCore::KeyframeEffect::startOrStopAccelerated): Start or stop the associated accelerated animation through the associated element's RenderBoxModelObject renderer. * animation/KeyframeEffect.h: * animation/WebAnimation.cpp: (WebCore::WebAnimation::acceleratedRunningStateDidChange): Called from AnimationEffect::applyAtLocalTime(), we forward to the DocumentTimeline the information that the animation will cross an active state boundary while allowing to be backed by hardware compositing. (WebCore::WebAnimation::startOrStopAccelerated): Forward to the associated KeyframeEffect that accelerated animation backing should be toggled. * animation/WebAnimation.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::requiresCompositingForAnimation const): Check via the renderer's element's DocumentTimeline that all running animations for this particular element are accelerated to ensure that the element will be hardware-composited. LayoutTests: [Web Animations] Perform hardware-composited animations when possible https://bugs.webkit.org/show_bug.cgi?id=179973 <rdar://problem/34953922> Reviewed by Dean Jackson. Add a series of tests to check that we use hardware-compositing for animations when possible. Specifically, we check that: 1. Specifying both accelerated and non-accelerated properties for a single animation does *not* yield hardware compositing (left-and-opacity-animation-yields-no-compositing.html). 2. Specifying both accelerated and non-accelerated properties via multiple animations does *not* yield hardware compositing (width-and-opacity-separate-animation-yields-no-compositing.html). 3. Specifying only accelerated properties *does* yield hardware compositing (opacity-animation-yields-compositing.html). 4. Hardware-composited animations no longer enforce hardware compositing after their completion (opacity-animation-no-longer-composited-upon-completion.html). * webanimations/left-and-opacity-animation-yields-no-compositing-expected.txt: Added. * webanimations/left-and-opacity-animation-yields-no-compositing.html: Added. * webanimations/opacity-animation-no-longer-composited-upon-completion-expected.txt: Added. * webanimations/opacity-animation-no-longer-composited-upon-completion.html: Added. * webanimations/opacity-animation-yields-compositing-expected.txt: Added. * webanimations/opacity-animation-yields-compositing.html: Added. * webanimations/width-and-opacity-separate-animation-yields-no-compositing-expected.txt: Added. * webanimations/width-and-opacity-separate-animation-yields-no-compositing.html: Added. Canonical link: https://commits.webkit.org/195996@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@225128 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-24 09:45:30 +00:00