Bug 244017 – Tiled layer flicker when an animation ends

• Component: Animations
• Status: RESOLVED FIXED

[Simon Fraser (smfr)]

Created attachment 461685 [details]
Testcase

Attached testcase shows a bug where sometimes there's a single frame where some tiles are missing at the end of the animation.

[Simon Fraser (smfr)]

While the animation is running, we adjust the tile coverage taking the animation motion into account (GraphicsLayer::adjustCoverageRectForMovement() etc). At some point, our KeyframeEffect animation code determines that the animation is complete, and in that same rendering update, we recompute the tile coverage assuming no animation. However, the Core Animation animation is still running in WindowServer, so the composited layer position continues to be affected by it (even though we’ve recomputed the tile coverage).

The animation is only removed from the CALayer in the next rendering update loop, one frame too late:

Page::updateRendering()
DocumentTimelinesController::updateAnimationsAndSendEvents for time 4.61s
AnimationEffect 0x4730b00c0 getBasicTiming - localTime 1482.00 activeAfterBoundaryTime 1500.00
KeyframeEffect 0x4730b00c0 getAnimatedStyle - progress 1.00
  blending transform from translateX(0px, 0px, 0px) to translateX(-100%, 0px, 0px) at 1.00 -> translate(-99.99%, 0px, 0px)
GraphicsLayer::adjustCoverageRectForMovement - previousVisibleRect (1119.29,0) width=1120.00 height=440, currentVisibleRect (1119.91,0) width=1120 height=440 expandedRect (1119.91,0) width=1121.24 height=440
TileGrid 0x4730216c0 (controller 0x4731500c0) revalidateTiles: bounds (0,0) width=2242 height=440 coverageRect(1119.91,0) width=1121.24 height=440 validation: []

Page::updateRendering()
AnimationEffect 0x4730b00c0 getBasicTiming - localTime 1532.00 activeAfterBoundaryTime 1500.00
KeyframeEffect 0x4730b00c0 getAnimatedStyle - progress unset
GraphicsLayer::adjustCoverageRectForMovement - previousVisibleRect (1119.91,0) width=1120 height=440, currentVisibleRect (5.40,0) width=1120 height=440 expandedRect (-2223.64,0) width=3349.04 height=440
TileGrid 0x4730216c0 (controller 0x4731500c0) revalidateTiles: bounds (0,0) width=2242 height=440 coverageRect(-2223.64,0) width=3349.04 height=440 validation: []

Page::updateRendering()
DocumentTimelinesController::updateAnimationsAndSendEvents for time 4.67s
DeclarativeAnimation::tick for element node 0x4a900d510 DIV 0x4a900d510 class='heroslide-set'
KeyframeEffect::invalidate on element node 0x4a900d510 DIV 0x4a900d510 class='heroslide-set'
GraphicsLayerCA 0x47303b370 id 91 removeAnimation keyframe-effect-2675c818-2317-40e3-9d74-32f9fc4036bd (is running 1)
animationDidStop <CAAnimationGroup: 0x6000007e0f20> finished 0
animationDidStop <CAAnimationGroup: 0x6000007e10c0> finished 0

[Simon Fraser (smfr)]

<rdar://89111231>

[Simon Fraser (smfr)]

For accelerated animations, DocumentTimeline::scheduleNextTick() starts a timer to trigger a rendering update for the next time that animations need servicing. However, there’s enough slop here that this timer fires too late:

DocumentTimeline 0x10511c500 scheduleNextTick - scheduleDelay 2.48s to fire at 68704.44432
…
DocumentTimeline 0x10511c500 scheduleAnimationResolution at 68704.55151 (timer fire)
…
Page::updateRendering() at 68704.55159

So this updateRendering() is the one too late to catch the end of the animation.

One option would be to always tick animations on every frame if a tiled layer is being animated (since we run rendering updates then every frame for tile coverage updates). Another would be to have the behavior of software animations match the CA animations, and behave like “fill-forward” until DocumentTimelinesController::updateAnimationsAndSendEvents() removes them. A third option would be to make scheduleNextTick use a slightly shorter delay.

[Simon Fraser (smfr)]

Pull request: https://github.com/WebKit/WebKit/pull/3392

[EWS]

Committed 253549@main (3292b5d3e182): <https://commits.webkit.org/253549@main>

Reviewed commits have been landed. Closing PR #3392 and removing active labels.

[Antoine Quint]

*** Bug 249091 has been marked as a duplicate of this bug. ***