Bug 310806 – [threaded-animations] REGRESSION: Flickery animations on https://pudding.cool/2026/03/ivf/

• Component: Animations
• Status: RESOLVED FIXED

[Antoine Quint]

Load https://pudding.cool/2026/03/ivf/ in STP 239 and click on "Parent" and notice how the two yellow bubbles that will appear on the right will not animate in as smoothly with the "Threaded Time-based Animations" flag enabled (the default) as it does when it's disabled.

[Antoine Quint]

rdar://173154867

[Antoine Quint]

Created attachment 478804 [details]
Flag disabled (GOOD)

[Antoine Quint]

Created attachment 478805 [details]
Flag enabled (BAD)

[Antoine Quint]

I meant the purple bubbles (not yellow).

[Antoine Quint]

Created attachment 478806 [details]
Frame by frame

The issue is that we see a flash of the final frame before the animation runs, as shown in the attached frame-by-frame screen recording.

[Antoine Quint]

Source code for the article is here: https://github.com/the-pudding/ivf.

[Antoine Quint]

The issue goes away if I remove this line (https://github.com/the-pudding/ivf/blob/925c270d44ab148eb3927d4e94e28bc0331a98a8/src/components/Html.svelte#L267):

        delay: prefersReducedMotion.current ? 0 : DELAY + i * 250

Now I need to figure out what this "fly" directive does under the hood (https://svelte.dev/docs/svelte/svelte-transition#fly) in order to reduce the content to a simple test.

[Antoine Quint]

This fly function is defined in https://github.com/sveltejs/svelte/blob/7be1a0247f1ea84db2e951ab27716c68de5b0650/packages/svelte/src/transition/index.js#L79 and looks like this:

	const style = getComputedStyle(node);
	const target_opacity = +style.opacity;
	const transform = style.transform === 'none' ? '' : style.transform;
	const od = target_opacity * (1 - opacity);
	const [x_value, x_unit] = split_css_unit(x);
	const [y_value, y_unit] = split_css_unit(y);
	return {
		delay,
		duration,
		easing,
		css: (t, u) => `
			transform: ${transform} translate(${(1 - t) * x_value}${x_unit}, ${(1 - t) * y_value}${y_unit});
			opacity: ${target_opacity - od * u}`
	};

[Antoine Quint]

This is going to be something to do with DOM mutations and transitions happening in quick succession.

[Antoine Quint]

Some very surprising choices made by Svelte here :)

First of all, the code above does not yield a CSS Transition but two JS-originated Web Animations. The first one is an animation that sets the base value for the duration of the delay. Then a second animation follows with 60 keyframes specified for each second the animation lasts! I guess this is so they have full control of how values are blended, but it's kind of overkill for a simple transition like the one I'm working with in my Svelte reduction…

Haven't quite gotten to the point where I have a fairly simple reproduction, but I am getting closer!

[Antoine Quint]

Here are links to the Svelte code:

Delay animation: https://github.com/sveltejs/svelte/blob/0e9e76f29262b5f64ac7a5d4db37ec83c9181634/packages/svelte/src/internal/client/dom/elements/transitions.js#L379
Active animation: https://github.com/sveltejs/svelte/blob/0e9e76f29262b5f64ac7a5d4db37ec83c9181634/packages/svelte/src/internal/client/dom/elements/transitions.js#L440

The `onfinish` callback to chain those.

[Antoine Quint]

Haven't quite managed to get it to reproduce as a standalone HTML file without using Svelte that could be used as a layout test, but I have enough to work on a fix.

[Antoine Quint]

Created attachment 478987 [details]
Reduction

Attached reduction exhibits the problem fairly reliably with STP 240 with Threaded Time-based Animations enabled.

Here's the basic code:

    const div = document.body.appendChild(document.createElement("div"));
    div.textContent = "Hello!";

    const delay = div.animate({ opacity: [0, 0] }, 1500);
    delay.onfinish = () => div.animate({ opacity: [0, 1] }, { duration: 1000, fill: 'forwards' });

What's happening is that there's a moment where the remote layer tree still has the "delay" animation but the second animation is not started yet and we're flashing the element at opacity=1 because the delay animation has fill="remove".

[Antoine Quint]

Created attachment 478991 [details]
Reduction

More deterministic reduction forcing the web process to be unresponsive for a while past the natural finish time for the initial animation.

[Antoine Quint]

Created attachment 478993 [details]
Reduction

Better reduction still with a single animation.

[Antoine Quint]

Here's how we approached this issue with the non-threaded code path in `GraphicsLayerCA::setupAnimation()`:

```
    case GraphicsLayerAnimation::FillMode::None:
        fillMode = PlatformCAAnimation::FillModeType::Forwards; // Use "forwards" rather than "removed" because the style system will remove the animation when it is finished. This avoids a flash.
        break;
```

So perhaps we just need to make it so that we use a simulated "forwards" fill mode for removed animations in the remote layer tree. However, we must be careful here because this is coming from a world where additivity was not a thing. We must only do this for the cast where an animation is not composing with another animation in the stack.

[Antoine Quint]

So simply forcing the fill to "forwards" for the remote layer tree animation addresses the issue both in the reduced test and on the live site, that's good! But I don't think we can simply do that in all cases where the fill-mode was specified as "none", we need to selectively determine whether that will create issue when animation effects are composed in the remote layer tree. We should be able to analyze this when a `RemoteAnimationStack` is created since we have all the timing information available to us, or perhaps do this on the web process side where much of the required surgery on effects is already performed.

[Antoine Quint]

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

[EWS]

Committed 310985@main (ebfab2641e50): <https://commits.webkit.org/310985@main>

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