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
|
|
|
(GraphicsLayer
|
|
|
|
(anchor 0.00 0.00)
|
|
|
|
(bounds 800.00 600.00)
|
|
|
|
(children 1
|
|
|
|
(GraphicsLayer
|
|
|
|
(bounds 800.00 600.00)
|
|
|
|
(contentsOpaque 1)
|
|
|
|
(children 1
|
|
|
|
(GraphicsLayer
|
|
|
|
(position 8.00 8.00)
|
|
|
|
(bounds 100.00 100.00)
|
2018-06-25 19:24:44 +00:00
|
|
|
(opacity 0.50)
|
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
|
|
|
(contentsOpaque 1)
|
|
|
|
)
|
|
|
|
)
|
|
|
|
)
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|