AnimationController.Progress always return zero

[douglassch]

Issue Type

[ x] Bug Report

Current Behavior

The reading of AnimationController.Progress property always return zero while running a KeyFrameAnimation.

Expected Behavior

Return the current playback position of the animation.

Steps to Reproduce (for bugs)

I'm using this sample as base code for test: https://github.com/microsoft/WindowsCompositionSamples/tree/master/Demos/Reference%20Demos/Animations_KeyFrame/Animate_Visual_Position

I added a timer callback to read the progress:

private void timerCallback(object state) { double progress = _target.TryGetAnimationController("Offset")?.Progress ?? double.NaN; Debug.WriteLine(progress.ToString()); }

The timer is enabled in the "Animate_Click" event after init the animation.

Your Environment

• SDK: 10.0.18362.0
• Operating System build: 1903(10.0 Build 18362)
• Visual Studio Version: 16.6.3

[mevey]

@douglassch AnimationController.Progress property always return zero while running a KeyFrameAnimation is by design. This is the same for any other property in composition that’s driven by an animation. We don’t do per-frame readback of any animated properties.

Here are some suggested workarounds:

• If the desired behavior is to get the progress value (after the animation is completed), then he can trigger the animation within a CompositionScopeBatch and read the progress value after the animation is completed.
• If the desired behavior is to reference the per-frame animating progress value, he can setup an ExpressionAnimation that references the AnimationController.Progress value.

[douglassch]

Thanks @mevey, I believe CompositionScopeBatch solves my problem, but I was confused about the API documentation because it seems that the property should be accessible throughout the animation once access to the controller is obtained.

I imagine that the derived class Object-> CompositionObject-> CompositionAnimation-> KeyFrameAnimation-> Vector3KeyFrameAnimation does not implement updating of the Progress property, is this expected or is it really an API bug?