Inconsistent/glitchy behavior for repeated explicit animations with starting value + delay

[Sergio0694]

Describe the bug

Using a XAML ScalarAnimation with a delay results in a weird snapping animation after the first time the animation is played. Running the same exact animation in C# using AnimationBuilder works fine instead. This issue is forcing us to write more animations in C# than we'd like in the Store client. We should investigate and fix this to ensure consistency between C#/XAML.

Steps to Reproduce

• Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

<Page
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:interactivity="using:Microsoft.Xaml.Interactivity"
    xmlns:interactions="using:Microsoft.Xaml.Interactions.Core"
    xmlns:mediaactions="using:Microsoft.Xaml.Interactions.Media"
    xmlns:ani="using:Microsoft.Toolkit.Uwp.UI.Animations"
    xmlns:behaviors="using:Microsoft.Toolkit.Uwp.UI.Behaviors"
    xmlns:core="using:Microsoft.Xaml.Interactions.Core"
    mc:Ignorable="d">

  <Button
    Background="Gray"
    Width="200"
    Height="200"
    HorizontalAlignment="Center"
    VerticalAlignment="Center"
    Content="🦙 Text">
    <ani:Explicit.Animations>
      <ani:AnimationSet x:Name="TestAnimation">
        <ani:ScalarAnimation
            Target="Translation.Y"
            From="96"
            To="0"
            Delay="0:0:1"
            Duration="0:0:0.6"/>
      </ani:AnimationSet>
    </ani:Explicit.Animations>

    <interactivity:Interaction.Behaviors>
      <interactions:EventTriggerBehavior EventName="Click">
        <behaviors:StartAnimationAction Animation="{Binding ElementName=TestAnimation}"/>
      </interactions:EventTriggerBehavior>
    </interactivity:Interaction.Behaviors>
  </Button>
</Page>

Note how the first time the animation is played it runs fine, but it-s glitchy after that.

Using C# works just fine instead:

AnimationBuilder.Create()
    .Translation(
        Axis.Y,
        from: 96,
        to: 0,
        delay: TimeSpan.FromMilliseconds(1000),
        duration: TimeSpan.FromMilliseconds(600))
    .Start((Button)sender);

Expected behavior

The XAML animation should play the exact same as the one declared using C#.

Screenshots

TrtkkqiLTU.mp4

Environment

NuGet Package(s): Microsoft.Toolkit.Uwp.UI.Animations/Behaviors 7.1.0

OS:

• Windows 11 Enterprise 22000.194

App min and target version:

• Fall Creators Update (16299)
• April 2018 Update (17134)
• October 2018 Update (17763)
• May 2019 Update (18362)
• May 2020 Update (19041)
• Insider Build ({build_number})
• 22000 SDK

Device form factor:

• Desktop
• Xbox
• Surface Hub
• IoT

Visual Studio version:

• 2017 (15.{minor_version})
• 2019 (16.4)
• 2022 (17.{minor_version})

Additional context

Hello Sergio0694, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[Sergio0694]

Alright so I've investigated this and managed to identify the cause of the issue.
This is affecting all our XAML animation types, specifically it's affecting all cases where AnimationSet is used.
What's triggering this glitch is this bit:

WindowsCommunityToolkit/Microsoft.Toolkit.Uwp.UI.Animations/Xaml/AnimationSet.cs

Lines 95 to 104 in 84adf91

	public Task StartAsync(UIElement element)
	{
	Stop(element);
	CancellationTokenSource cancellationTokenSource = new();
	this.cancellationTokenMap.AddOrUpdate(element, cancellationTokenSource);
	return StartAsync(element, cancellationTokenSource.Token);
	}

Here we're tracking a CancellationTokenSource for all animations started without a token (this applies to all XAML ones by default), so that they're stopped right before the new one starts, to ensure there are no weird wonky behaviors with multiple overlapping animations running concurrently. This is needed also because as animation sets can mix composition and XAML animations, these two animation types exhibit different behaviors with respect to overlapping animations (eg. I'm pretty sure starting the same Storyboard multiple times on the same item will just restart it and cancel the old execution, whereas this doesn't apply to composition animations). That bit is causing this callback to be invoked (synchronously) before starting new animations:

WindowsCommunityToolkit/Microsoft.Toolkit.Uwp.UI.Animations/Builders/AnimationBuilder.cs

Lines 441 to 451 in 84adf91

	static void Stop(object state)
	{
	(List<(CompositionObject Target, string Path)>? animations, Storyboard? storyboard) = ((List<(CompositionObject, string)>?, Storyboard?))state;
	if (animations is not null)
	{
	foreach (var (target, path) in animations)
	{
	target.StopAnimation(path);
	}
	}

The crux of that issue seems to be that target.StopAnimation(path) call. It looks like when a given composition animation is stopped and then started again, something glitches out when we also have a delay and the SetInitialValueBeforeDelay mode. To reproduce this with a minimal repro and without the Toolkit dependency at all, here is a snippet:

UIElement element = (UIElement)sender;
Visual visual = ElementCompositionPreview.GetElementVisual(element);

ElementCompositionPreview.SetIsTranslationEnabled(element, true);

ScalarKeyFrameAnimation animation = visual.Compositor.CreateScalarKeyFrameAnimation();

animation.Duration = TimeSpan.FromMilliseconds(600);
animation.DelayTime = TimeSpan.FromMilliseconds(1000);
animation.DelayBehavior = AnimationDelayBehavior.SetInitialValueBeforeDelay;
animation.InsertKeyFrame(0, 96);
animation.InsertKeyFrame(1, 0);
animation.Target = "Translation.Y";

// Stop
visual.StopAnimation(animation.Target);

// Start
visual.StartAnimation(animation.Target, animation);

This is enough to reproduce the issue. The first time this animation is started, it runs just fine, and following times it just first jumps to the correct initial value, then immediately resets back to the current position before that, and then once the delay is over it snaps back again to the correct initial value and starts playing. This doesn't seem correct to me (as in, I would be surprised if this was by design), as there are two possible scenarios that I can see here:

• StopAnimation is supposed to stop the current animation from playing (there's none here, the previous animation has already ended anyway), and not modify any of the underlying visual properties for the target object. If this is the case, then I can't explain why is it that stopping the animation causes the object to bounce down first and then back up.
• StopAnimation is supposed to set the underlying visual properties to the starting ones that the object would get if that animation was played. In this case, the starting position would be 96 here (as that's the first keyframe with progress set to 0), so again I can't explain why is it that the item then bounces back and forth between 96 and 0 before the animation starts playing.

So either way the current behavior seems (1) incorrect and (2) unrelated from the Toolkit specifically.
Is this a platform bug? cc. @StephenLPeters could you help us figure out who we should ping to ask about this? Should we also open an issue on the WinUI repo for this? If so just let me know and I'll be happy to create one with these findings 😊

[StephenLPeters]

@Sergio0694 I beleive the https://docs.microsoft.com/en-us/uwp/api/windows.ui.composition.animationstopbehavior?view=winrt-22000 stop behavior property is supposed to dictate this behavior. What you've described does seem like a bug to me. although getting a GIF of it in the issue would make me more confident I understand the issue.

[raymond-wh-leung]

I’m not 100% positive what’s causing the jump, but I think one thing you can try is to just skip the StopAnimation() call.
The StartAnimation call() would stop existing animation if any, and without triggering any StopBehavior.