- Revision
- 256369
- Author
- alanc...@apple.com
- Date
- 2020-02-11 14:03:33 -0800 (Tue, 11 Feb 2020)
Log Message
Cherry-pick r256214. rdar://problem/59349205
WebContent jetsams on Sony lens webpage due to spike of IOSurfaces
https://bugs.webkit.org/show_bug.cgi?id=207493
rdar://problem/59020443
Reviewed by Zalan Bujtas.
Source/WebCore:
There were three issues that contributed to massive backing store allocation on
<https://www.sony.com/electronics/lenses/t/camera-lenses>.
The first, fixed in r256095, was that the Web Animations code unioned the untransitioning
bounds with the transitioning bounds, causing the computation of large extent rects.
The second, fixed in r256181, was that GraphicsLayerCA would keep hold of a transform
animation for an extra frame, causing a rendering update where
RenderLayerBacking::updateGeometry() would have cleared the extent, but GraphicsLayerCA
still thought transform was animating, causing GraphicsLayerCA::updateCoverage() to keep
backing store attached.
This patch is the final fix; when animations start and end, we need to ensure that
RenderLayerBacking::updateGeometry() is called so that we compute the animation extent in
the same frame that adds the animation.
Test: compositing/backing/transition-extent.html
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::startAnimation):
(WebCore::RenderLayerBacking::animationFinished):
LayoutTests:
Test with an out-of-view transitioning element which should not get backing store.
* compositing/backing/transition-extent-expected.txt: Added.
* compositing/backing/transition-extent.html: Added.
* platform/ios-wk2/compositing/backing/transition-extent-expected.txt: Added.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Modified Paths
Added Paths
Diff
Modified: branches/safari-609.1.17.1-branch/LayoutTests/ChangeLog (256368 => 256369)
--- branches/safari-609.1.17.1-branch/LayoutTests/ChangeLog 2020-02-11 22:03:29 UTC (rev 256368)
+++ branches/safari-609.1.17.1-branch/LayoutTests/ChangeLog 2020-02-11 22:03:33 UTC (rev 256369)
@@ -1,59 +1,102 @@
2020-02-11 Alan Coon <alanc...@apple.com>
- Cherry-pick r256181. rdar://problem/59349184
+ Cherry-pick r256214. rdar://problem/59349205
- There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
- https://bugs.webkit.org/show_bug.cgi?id=207361
- <rdar://problem/59280370>
+ WebContent jetsams on Sony lens webpage due to spike of IOSurfaces
+ https://bugs.webkit.org/show_bug.cgi?id=207493
+ rdar://problem/59020443
- Reviewed by Simon Fraser.
-
+ Reviewed by Zalan Bujtas.
Source/WebCore:
- Animations should be removed from GraphicsLayersCAs in the same rendering update that changes the playState of the
- animation to "finished", to avoid layer flush where a GraphicsLayersCAs has no extent set, but thinks there is
- an active transform animation.
+ There were three issues that contributed to massive backing store allocation on
+ <https://www.sony.com/electronics/lenses/t/camera-lenses>.
- To do this, instead of enqueuing accelerated actions when resolving animations during style resolution, in
- KeyframeAnimation::apply(), we enqueue them as soon as an animation's current time may have changed: in
- WebAnimation::tick() and WebAnimation::play() with supporting functions newly exposed on AnimationEffect.
+ The first, fixed in r256095, was that the Web Animations code unioned the untransitioning
+ bounds with the transitioning bounds, causing the computation of large extent rects.
- Now, accelerated animations are enqueued and applied during the "update animations and send events" procedure.
+ The second, fixed in r256181, was that GraphicsLayerCA would keep hold of a transform
+ animation for an extra frame, causing a rendering update where
+ RenderLayerBacking::updateGeometry() would have cleared the extent, but GraphicsLayerCA
+ still thought transform was animating, causing GraphicsLayerCA::updateCoverage() to keep
+ backing store attached.
- * animation/AnimationEffect.h:
- * animation/KeyframeEffect.cpp:
- (WebCore::KeyframeEffect::apply):
- (WebCore::KeyframeEffect::updateAcceleratedActions):
- (WebCore::KeyframeEffect::animationDidTick):
- (WebCore::KeyframeEffect::animationDidPlay):
- * animation/KeyframeEffect.h:
- * animation/WebAnimation.cpp:
- (WebCore::WebAnimation::play):
- (WebCore::WebAnimation::tick):
+ This patch is the final fix; when animations start and end, we need to ensure that
+ RenderLayerBacking::updateGeometry() is called so that we compute the animation extent in
+ the same frame that adds the animation.
+ Test: compositing/backing/transition-extent.html
+
+ * rendering/RenderLayerBacking.cpp:
+ (WebCore::RenderLayerBacking::startAnimation):
+ (WebCore::RenderLayerBacking::animationFinished):
+
LayoutTests:
- Lower the number of frames to wait after an animation completes by one to check that the accelerated animation has been removed
- to show that we enqueue accelerated actions as part of the "update animations and send events" procedure.
+ Test with an out-of-view transitioning element which should not get backing store.
- * webanimations/accelerated-animation-removal-upon-transition-completion.html: Added.
+ * compositing/backing/transition-extent-expected.txt: Added.
+ * compositing/backing/transition-extent.html: Added.
+ * platform/ios-wk2/compositing/backing/transition-extent-expected.txt: Added.
-
- git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2020-02-10 Antoine Quint <grao...@webkit.org>
+ 2020-02-11 Alan Coon <alanc...@apple.com>
- There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
- https://bugs.webkit.org/show_bug.cgi?id=207361
- <rdar://problem/59280370>
+ Cherry-pick r256181. rdar://problem/59349184
- Reviewed by Simon Fraser.
+ There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
+ https://bugs.webkit.org/show_bug.cgi?id=207361
+ <rdar://problem/59280370>
- Lower the number of frames to wait after an animation completes by one to check that the accelerated animation has been removed
- to show that we enqueue accelerated actions as part of the "update animations and send events" procedure.
+ Reviewed by Simon Fraser.
- * webanimations/accelerated-animation-removal-upon-transition-completion.html: Added.
+ Source/WebCore:
+ Animations should be removed from GraphicsLayersCAs in the same rendering update that changes the playState of the
+ animation to "finished", to avoid layer flush where a GraphicsLayersCAs has no extent set, but thinks there is
+ an active transform animation.
+
+ To do this, instead of enqueuing accelerated actions when resolving animations during style resolution, in
+ KeyframeAnimation::apply(), we enqueue them as soon as an animation's current time may have changed: in
+ WebAnimation::tick() and WebAnimation::play() with supporting functions newly exposed on AnimationEffect.
+
+ Now, accelerated animations are enqueued and applied during the "update animations and send events" procedure.
+
+ * animation/AnimationEffect.h:
+ * animation/KeyframeEffect.cpp:
+ (WebCore::KeyframeEffect::apply):
+ (WebCore::KeyframeEffect::updateAcceleratedActions):
+ (WebCore::KeyframeEffect::animationDidTick):
+ (WebCore::KeyframeEffect::animationDidPlay):
+ * animation/KeyframeEffect.h:
+ * animation/WebAnimation.cpp:
+ (WebCore::WebAnimation::play):
+ (WebCore::WebAnimation::tick):
+
+ LayoutTests:
+
+ Lower the number of frames to wait after an animation completes by one to check that the accelerated animation has been removed
+ to show that we enqueue accelerated actions as part of the "update animations and send events" procedure.
+
+ * webanimations/accelerated-animation-removal-upon-transition-completion.html: Added.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2020-02-10 Antoine Quint <grao...@webkit.org>
+
+ There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
+ https://bugs.webkit.org/show_bug.cgi?id=207361
+ <rdar://problem/59280370>
+
+ Reviewed by Simon Fraser.
+
+ Lower the number of frames to wait after an animation completes by one to check that the accelerated animation has been removed
+ to show that we enqueue accelerated actions as part of the "update animations and send events" procedure.
+
+ * webanimations/accelerated-animation-removal-upon-transition-completion.html: Added.
+
2020-02-11 Alan Coon <alanc...@apple.com>
Cherry-pick r256095. rdar://problem/59349202
@@ -85,6 +128,20 @@
* page/animation/KeyframeAnimation.cpp:
(WebCore::KeyframeAnimation::computeExtentOfTransformAnimation const):
+2020-02-10 Simon Fraser <simon.fra...@apple.com>
+
+ WebContent jetsams on Sony lens webpage due to spike of IOSurfaces
+ https://bugs.webkit.org/show_bug.cgi?id=207493
+ rdar://problem/59020443
+
+ Reviewed by Zalan Bujtas.
+
+ Test with an out-of-view transitioning element which should not get backing store.
+
+ * compositing/backing/transition-extent-expected.txt: Added.
+ * compositing/backing/transition-extent.html: Added.
+ * platform/ios-wk2/compositing/backing/transition-extent-expected.txt: Added.
+
LayoutTests:
New test that checks backing store attachment and overlap for an element which is positioned in-view,
Added: branches/safari-609.1.17.1-branch/LayoutTests/compositing/backing/transition-extent-expected.txt (0 => 256369)
--- branches/safari-609.1.17.1-branch/LayoutTests/compositing/backing/transition-extent-expected.txt (rev 0)
+++ branches/safari-609.1.17.1-branch/LayoutTests/compositing/backing/transition-extent-expected.txt 2020-02-11 22:03:33 UTC (rev 256369)
@@ -0,0 +1,31 @@
+The second box should not have attached backing store.
+
+(GraphicsLayer
+ (anchor 0.00 0.00)
+ (bounds 785.00 2024.00)
+ (backingStoreAttached 1)
+ (children 1
+ (GraphicsLayer
+ (bounds 785.00 2024.00)
+ (contentsOpaque 1)
+ (backingStoreAttached 1)
+ (children 2
+ (GraphicsLayer
+ (position 20.00 20.00)
+ (bounds 100.00 100.00)
+ (contentsOpaque 1)
+ (drawsContent 1)
+ (backingStoreAttached 1)
+ )
+ (GraphicsLayer
+ (position 20.00 1500.00)
+ (bounds 100.00 100.00)
+ (contentsOpaque 1)
+ (drawsContent 1)
+ (backingStoreAttached 0)
+ )
+ )
+ )
+ )
+)
+visible boxhidden box
Added: branches/safari-609.1.17.1-branch/LayoutTests/compositing/backing/transition-extent.html (0 => 256369)
--- branches/safari-609.1.17.1-branch/LayoutTests/compositing/backing/transition-extent.html (rev 0)
+++ branches/safari-609.1.17.1-branch/LayoutTests/compositing/backing/transition-extent.html 2020-02-11 22:03:33 UTC (rev 256369)
@@ -0,0 +1,55 @@
+<!DOCTYPE html>
+<html>
+<head>
+ <style>
+ body {
+ height: 2000px;
+ }
+
+ .box {
+ position: absolute;
+ left: 20px;
+ top: 20px;
+ width: 100px;
+ height: 100px;
+ background-color: silver;
+ transition: transform 2s;
+ transform: rotate3d(0, 0, 1, 0deg)
+ }
+
+ body.changed .box {
+ transform: rotate3d(0, 0, 1, -180deg);
+ }
+
+ .invisible {
+ top: 1500px;
+ }
+ </style>
+ <script>
+ if (window.testRunner) {
+ testRunner.dumpAsText();
+ testRunner.waitUntilDone();
+ }
+ window.addEventListener('load', () => {
+ let box = document.querySelector('.box');
+ box.addEventListener('transitionstart', () => {
+ requestAnimationFrame(() => {
+ var out = document.getElementById('layers');
+ out.innerText = internals.layerTreeAsText(document, internals.LAYER_TREE_INCLUDES_BACKING_STORE_ATTACHED);
+ testRunner.notifyDone();
+ });
+ }, false);
+
+ requestAnimationFrame(() => {
+ document.body.classList.add('changed');
+ });
+ }, false);
+ </script>
+</head>
+<body>
+ <p>The second box should not have attached backing store.</p>
+<pre id="layers"></pre>
+ <div class="box">visible box</div>
+ <div class="invisible box">hidden box</div>
+</body>
+</html>
Added: branches/safari-609.1.17.1-branch/LayoutTests/platform/ios-wk2/compositing/backing/transition-extent-expected.txt (0 => 256369)
--- branches/safari-609.1.17.1-branch/LayoutTests/platform/ios-wk2/compositing/backing/transition-extent-expected.txt (rev 0)
+++ branches/safari-609.1.17.1-branch/LayoutTests/platform/ios-wk2/compositing/backing/transition-extent-expected.txt 2020-02-11 22:03:33 UTC (rev 256369)
@@ -0,0 +1,31 @@
+The second box should not have attached backing store.
+
+(GraphicsLayer
+ (anchor 0.00 0.00)
+ (bounds 800.00 2024.00)
+ (backingStoreAttached 1)
+ (children 1
+ (GraphicsLayer
+ (bounds 800.00 2024.00)
+ (contentsOpaque 1)
+ (backingStoreAttached 1)
+ (children 2
+ (GraphicsLayer
+ (position 20.00 20.00)
+ (bounds 100.00 100.00)
+ (contentsOpaque 1)
+ (drawsContent 1)
+ (backingStoreAttached 1)
+ )
+ (GraphicsLayer
+ (position 20.00 1500.00)
+ (bounds 100.00 100.00)
+ (contentsOpaque 1)
+ (drawsContent 1)
+ (backingStoreAttached 0)
+ )
+ )
+ )
+ )
+)
+visible boxhidden box
Modified: branches/safari-609.1.17.1-branch/Source/WebCore/ChangeLog (256368 => 256369)
--- branches/safari-609.1.17.1-branch/Source/WebCore/ChangeLog 2020-02-11 22:03:29 UTC (rev 256368)
+++ branches/safari-609.1.17.1-branch/Source/WebCore/ChangeLog 2020-02-11 22:03:33 UTC (rev 256369)
@@ -1,75 +1,118 @@
2020-02-11 Alan Coon <alanc...@apple.com>
- Cherry-pick r256181. rdar://problem/59349184
+ Cherry-pick r256214. rdar://problem/59349205
- There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
- https://bugs.webkit.org/show_bug.cgi?id=207361
- <rdar://problem/59280370>
+ WebContent jetsams on Sony lens webpage due to spike of IOSurfaces
+ https://bugs.webkit.org/show_bug.cgi?id=207493
+ rdar://problem/59020443
- Reviewed by Simon Fraser.
-
+ Reviewed by Zalan Bujtas.
Source/WebCore:
- Animations should be removed from GraphicsLayersCAs in the same rendering update that changes the playState of the
- animation to "finished", to avoid layer flush where a GraphicsLayersCAs has no extent set, but thinks there is
- an active transform animation.
+ There were three issues that contributed to massive backing store allocation on
+ <https://www.sony.com/electronics/lenses/t/camera-lenses>.
- To do this, instead of enqueuing accelerated actions when resolving animations during style resolution, in
- KeyframeAnimation::apply(), we enqueue them as soon as an animation's current time may have changed: in
- WebAnimation::tick() and WebAnimation::play() with supporting functions newly exposed on AnimationEffect.
+ The first, fixed in r256095, was that the Web Animations code unioned the untransitioning
+ bounds with the transitioning bounds, causing the computation of large extent rects.
- Now, accelerated animations are enqueued and applied during the "update animations and send events" procedure.
+ The second, fixed in r256181, was that GraphicsLayerCA would keep hold of a transform
+ animation for an extra frame, causing a rendering update where
+ RenderLayerBacking::updateGeometry() would have cleared the extent, but GraphicsLayerCA
+ still thought transform was animating, causing GraphicsLayerCA::updateCoverage() to keep
+ backing store attached.
- * animation/AnimationEffect.h:
- * animation/KeyframeEffect.cpp:
- (WebCore::KeyframeEffect::apply):
- (WebCore::KeyframeEffect::updateAcceleratedActions):
- (WebCore::KeyframeEffect::animationDidTick):
- (WebCore::KeyframeEffect::animationDidPlay):
- * animation/KeyframeEffect.h:
- * animation/WebAnimation.cpp:
- (WebCore::WebAnimation::play):
- (WebCore::WebAnimation::tick):
+ This patch is the final fix; when animations start and end, we need to ensure that
+ RenderLayerBacking::updateGeometry() is called so that we compute the animation extent in
+ the same frame that adds the animation.
+ Test: compositing/backing/transition-extent.html
+
+ * rendering/RenderLayerBacking.cpp:
+ (WebCore::RenderLayerBacking::startAnimation):
+ (WebCore::RenderLayerBacking::animationFinished):
+
LayoutTests:
- Lower the number of frames to wait after an animation completes by one to check that the accelerated animation has been removed
- to show that we enqueue accelerated actions as part of the "update animations and send events" procedure.
+ Test with an out-of-view transitioning element which should not get backing store.
- * webanimations/accelerated-animation-removal-upon-transition-completion.html: Added.
+ * compositing/backing/transition-extent-expected.txt: Added.
+ * compositing/backing/transition-extent.html: Added.
+ * platform/ios-wk2/compositing/backing/transition-extent-expected.txt: Added.
-
- git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2020-02-10 Antoine Quint <grao...@webkit.org>
+ 2020-02-11 Alan Coon <alanc...@apple.com>
- There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
- https://bugs.webkit.org/show_bug.cgi?id=207361
- <rdar://problem/59280370>
+ Cherry-pick r256181. rdar://problem/59349184
- Reviewed by Simon Fraser.
+ There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
+ https://bugs.webkit.org/show_bug.cgi?id=207361
+ <rdar://problem/59280370>
- Animations should be removed from GraphicsLayersCAs in the same rendering update that changes the playState of the
- animation to "finished", to avoid layer flush where a GraphicsLayersCAs has no extent set, but thinks there is
- an active transform animation.
+ Reviewed by Simon Fraser.
- To do this, instead of enqueuing accelerated actions when resolving animations during style resolution, in
- KeyframeAnimation::apply(), we enqueue them as soon as an animation's current time may have changed: in
- WebAnimation::tick() and WebAnimation::play() with supporting functions newly exposed on AnimationEffect.
+ Source/WebCore:
- Now, accelerated animations are enqueued and applied during the "update animations and send events" procedure.
+ Animations should be removed from GraphicsLayersCAs in the same rendering update that changes the playState of the
+ animation to "finished", to avoid layer flush where a GraphicsLayersCAs has no extent set, but thinks there is
+ an active transform animation.
- * animation/AnimationEffect.h:
- * animation/KeyframeEffect.cpp:
- (WebCore::KeyframeEffect::apply):
- (WebCore::KeyframeEffect::updateAcceleratedActions):
- (WebCore::KeyframeEffect::animationDidTick):
- (WebCore::KeyframeEffect::animationDidPlay):
- * animation/KeyframeEffect.h:
- * animation/WebAnimation.cpp:
- (WebCore::WebAnimation::play):
- (WebCore::WebAnimation::tick):
+ To do this, instead of enqueuing accelerated actions when resolving animations during style resolution, in
+ KeyframeAnimation::apply(), we enqueue them as soon as an animation's current time may have changed: in
+ WebAnimation::tick() and WebAnimation::play() with supporting functions newly exposed on AnimationEffect.
+ Now, accelerated animations are enqueued and applied during the "update animations and send events" procedure.
+
+ * animation/AnimationEffect.h:
+ * animation/KeyframeEffect.cpp:
+ (WebCore::KeyframeEffect::apply):
+ (WebCore::KeyframeEffect::updateAcceleratedActions):
+ (WebCore::KeyframeEffect::animationDidTick):
+ (WebCore::KeyframeEffect::animationDidPlay):
+ * animation/KeyframeEffect.h:
+ * animation/WebAnimation.cpp:
+ (WebCore::WebAnimation::play):
+ (WebCore::WebAnimation::tick):
+
+ LayoutTests:
+
+ Lower the number of frames to wait after an animation completes by one to check that the accelerated animation has been removed
+ to show that we enqueue accelerated actions as part of the "update animations and send events" procedure.
+
+ * webanimations/accelerated-animation-removal-upon-transition-completion.html: Added.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2020-02-10 Antoine Quint <grao...@webkit.org>
+
+ There's an event loop cycle between an animation finishing, and it being removed from GraphicsLayerCA
+ https://bugs.webkit.org/show_bug.cgi?id=207361
+ <rdar://problem/59280370>
+
+ Reviewed by Simon Fraser.
+
+ Animations should be removed from GraphicsLayersCAs in the same rendering update that changes the playState of the
+ animation to "finished", to avoid layer flush where a GraphicsLayersCAs has no extent set, but thinks there is
+ an active transform animation.
+
+ To do this, instead of enqueuing accelerated actions when resolving animations during style resolution, in
+ KeyframeAnimation::apply(), we enqueue them as soon as an animation's current time may have changed: in
+ WebAnimation::tick() and WebAnimation::play() with supporting functions newly exposed on AnimationEffect.
+
+ Now, accelerated animations are enqueued and applied during the "update animations and send events" procedure.
+
+ * animation/AnimationEffect.h:
+ * animation/KeyframeEffect.cpp:
+ (WebCore::KeyframeEffect::apply):
+ (WebCore::KeyframeEffect::updateAcceleratedActions):
+ (WebCore::KeyframeEffect::animationDidTick):
+ (WebCore::KeyframeEffect::animationDidPlay):
+ * animation/KeyframeEffect.h:
+ * animation/WebAnimation.cpp:
+ (WebCore::WebAnimation::play):
+ (WebCore::WebAnimation::tick):
+
2020-02-11 Alan Coon <alanc...@apple.com>
Cherry-pick r256095. rdar://problem/59349202
@@ -154,6 +197,36 @@
Cherry-pick r255810. rdar://problem/59349189
+2020-02-10 Simon Fraser <simon.fra...@apple.com>
+
+ WebContent jetsams on Sony lens webpage due to spike of IOSurfaces
+ https://bugs.webkit.org/show_bug.cgi?id=207493
+ rdar://problem/59020443
+
+ Reviewed by Zalan Bujtas.
+
+ There were three issues that contributed to massive backing store allocation on
+ <https://www.sony.com/electronics/lenses/t/camera-lenses>.
+
+ The first, fixed in r256095, was that the Web Animations code unioned the untransitioning
+ bounds with the transitioning bounds, causing the computation of large extent rects.
+
+ The second, fixed in r256181, was that GraphicsLayerCA would keep hold of a transform
+ animation for an extra frame, causing a rendering update where
+ RenderLayerBacking::updateGeometry() would have cleared the extent, but GraphicsLayerCA
+ still thought transform was animating, causing GraphicsLayerCA::updateCoverage() to keep
+ backing store attached.
+
+ This patch is the final fix; when animations start and end, we need to ensure that
+ RenderLayerBacking::updateGeometry() is called so that we compute the animation extent in
+ the same frame that adds the animation.
+
+ Test: compositing/backing/transition-extent.html
+
+ * rendering/RenderLayerBacking.cpp:
+ (WebCore::RenderLayerBacking::startAnimation):
+ (WebCore::RenderLayerBacking::animationFinished):
+
[Web Animations] Canceling an accelerated animation before it was committed does not prevent it from playing
https://bugs.webkit.org/show_bug.cgi?id=207253
<rdar://problem/59143624>
Modified: branches/safari-609.1.17.1-branch/Source/WebCore/rendering/RenderLayerBacking.cpp (256368 => 256369)
--- branches/safari-609.1.17.1-branch/Source/WebCore/rendering/RenderLayerBacking.cpp 2020-02-11 22:03:29 UTC (rev 256368)
+++ branches/safari-609.1.17.1-branch/Source/WebCore/rendering/RenderLayerBacking.cpp 2020-02-11 22:03:33 UTC (rev 256369)
@@ -3283,8 +3283,10 @@
didAnimate = true;
#endif
- if (didAnimate)
+ if (didAnimate) {
m_owningLayer.setNeedsPostLayoutCompositingUpdate();
+ m_owningLayer.setNeedsCompositingGeometryUpdate();
+ }
return didAnimate;
}
@@ -3303,6 +3305,7 @@
{
m_graphicsLayer->removeAnimation(animationName);
m_owningLayer.setNeedsPostLayoutCompositingUpdate();
+ m_owningLayer.setNeedsCompositingGeometryUpdate();
}
bool RenderLayerBacking::startTransition(double timeOffset, CSSPropertyID property, const RenderStyle* fromStyle, const RenderStyle* toStyle)
