Bug 171060

Summary: REGRESSION (r215469): [ios-simulator-wk2] LayoutTest compositing/animation/animation-backing.html is a flaky failure
Product: WebKit Reporter: Ryan Haddad <ryanhaddad>
Component: AnimationsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, dino, koivisto, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch
none
patch
simon.fraser: review-
patch none

Ryan Haddad
Reported 2017-04-20 09:41:43 PDT
[ios-simulator] LayoutTest compositing/animation/animation-backing.html is a flaky failure https://build.webkit.org/results/Apple%20iOS%2010%20Simulator%20Release%20WK2%20(Tests)/r215557%20(805)/results.html https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=compositing%2Fanimation%2Fanimation-backing.html --- /Volumes/Data/slave/ios-simulator-10-release-tests-wk2/build/layout-test-results/compositing/animation/animation-backing-expected.txt +++ /Volumes/Data/slave/ios-simulator-10-release-tests-wk2/build/layout-test-results/compositing/animation/animation-backing-actual.txt @@ -1 +1 @@ -Saw layer flushes during animation: PASS +No layer flushes during animation: FAIL
Attachments
patch (11.18 KB, patch)
2017-04-21 10:53 PDT, Antti Koivisto
no flags
patch (9.62 KB, patch)
2017-04-24 06:00 PDT, Antti Koivisto
simon.fraser: review-
patch (6.45 KB, patch)
2017-04-25 11:02 PDT, Antti Koivisto
no flags
Ryan Haddad
Comment 1 2017-04-20 09:44:51 PDT
It looks like this regressed with "Enable optimized layer flushes on iOS" https://trac.webkit.org/changeset/215469/webkit
Antti Koivisto
Comment 2 2017-04-20 13:43:38 PDT
I'll take a look.
Simon Fraser (smfr)
Comment 3 2017-04-21 03:56:26 PDT
The flush needs to travers tiled layers under animating layers, because we have to recompute the coverage rect as the animation runs. After your changes, how do we ensure the recomputation of coverage rects on all layers with scrolling etc, which is used to drop backing store outside the viewport, and compute the right tiling for tiled layers?
Antti Koivisto
Comment 4 2017-04-21 05:50:54 PDT
(In reply to Simon Fraser (smfr) from comment #3) > The flush needs to travers tiled layers under animating layers, because we > have to recompute the coverage rect as the animation runs. > > After your changes, how do we ensure the recomputation of coverage rects on > all layers with scrolling etc, which is used to drop backing store outside > the viewport, and compute the right tiling for tiled layers? We traverse all descendants if coverage rect changes. For scrolling we take care to invalidate the scrolling layers so coverage gets recomputed. I assume we are missing or misoptimizing some invalidation with animations.
Antti Koivisto
Comment 5 2017-04-21 05:59:35 PDT
We can probably just invalidate all layers with accelerated animations in progress.
Antti Koivisto
Comment 6 2017-04-21 10:53:18 PDT
Simon Fraser (smfr)
Comment 7 2017-04-21 14:04:55 PDT
Comment on attachment 307750 [details] patch I don't think you need all this. We already have CommitState.ancestorHasTransformAnimation, why can't you key off of that?
Antti Koivisto
Comment 8 2017-04-21 15:21:52 PDT
Possibly. What I need is answer to "Does this layer have any descendants with accelerated transform animations?" Do we have this somewhere already? Cleary I could just traverse the entire layer tree but that is much slower than what the patch does (just traverses the active animations).
Radar WebKit Bug Importer
Comment 9 2017-04-21 19:49:52 PDT
Simon Fraser (smfr)
Comment 10 2017-04-22 02:17:10 PDT
Should be easy to add "descendant has accelerated transform animation" as a post-traversal bit set. I would prefer to keep this code in GraphicsLayerCA.
Antti Koivisto
Comment 11 2017-04-22 02:26:33 PDT
(In reply to Simon Fraser (smfr) from comment #10) > Should be easy to add "descendant has accelerated transform animation" as a > post-traversal bit set. I would prefer to keep this code in GraphicsLayerCA. Yeah, should be doable.
Antti Koivisto
Comment 12 2017-04-24 06:00:49 PDT
Created attachment 307968 [details] patch GraphicsLayerCA only (almost) patch
Simon Fraser (smfr)
Comment 13 2017-04-25 08:46:35 PDT
Comment on attachment 307968 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=307968&action=review > Source/WebCore/rendering/RenderLayerBacking.cpp:961 > + bool hasAcceleratedTransformAnimation = renderer().animation().isRunningAcceleratedAnimationOnRenderer(renderer(), CSSPropertyTransform, AnimationBase::Running | AnimationBase::Paused); > + m_graphicsLayer->setHasAcceleratedTransformAnimation(hasAcceleratedTransformAnimation); > + if (!hasAcceleratedTransformAnimation) I don't think you need to set this from outside of GraphicsLayer(CA). GraphicsLayerCA::isRunningTransformAnimation() knows this, and GraphicsLayerCA::updateAnimations() can set or clear the state.
Antti Koivisto
Comment 14 2017-04-25 11:02:53 PDT
WebKit Commit Bot
Comment 15 2017-04-25 12:20:21 PDT
Comment on attachment 308117 [details] patch Clearing flags on attachment: 308117 Committed r215750: <http://trac.webkit.org/changeset/215750>
WebKit Commit Bot
Comment 16 2017-04-25 12:20:23 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.