Fix issue with ProgressRing not acting correctly when moving backwards

[marcelwgn]

Description

When next value is below current value, we animate backwards instead of going to 100% and then to the value.
This is partially broken right now, when going backwards, the progressring jumps instead of animating.

Motivation and Context

Closes #3173 , Closes #3562

How Has This Been Tested?

Tested manually.

Screenshots (if appropriate):

The dark spot on the progress ring is a compression artifact, not visible when running the app.

[mdtauk]

Is there a way to control the playback speed with the Lottie control?

Changing the value from 10 to 90 would take longer to animate than something like 30 to 40.

Ideally the animation speed would adjust to a duration that could be set, so all transitions take the same amount of time.

Also, this should work when animating forward and backward.

[marcelwgn]

Is there a way to control the playback speed with the Lottie control?

Yes, in fact that is what this PR is utilizing.

Regarding the speed, I don't think that we need to do adjustments there, going from 1 to 100 takes much more time than going from 1 to 11:

1 to 11	1 to 100

Also, this should work when animating forward and backward.

Yes, definitely!

[marcelwgn]

Ideally the animation speed would adjust to a duration that could be set, so all transitions take the same amount of time.

@MarissaMatt FYI since this would introduce a new API

[MarissaMatt]

@chingucoding @mdtauk I think the playback speed should be considered with the other property additions that were proposed for ProgressRing (Ring Thickness & Color Property). I'll update the proposal I made for the thickness to include the duration as well so we can track all three in one proposal.

[MarissaMatt]

@chingucoding just to add a comment on the PR as well the jumping behavior is the expected behavior for moving backwards.

[ranjeshj]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mdtauk]

@chingucoding @mdtauk I think the playback speed should be considered with the other property additions that were proposed for ProgressRing (Ring Thickness & Color Property). I'll update the proposal I made for the thickness to include the duration as well so we can track all three in one proposal.

Now another question becomes, should both Determinate and Indeterminate animations be affected by the duration? So a single loop of the Indeterminate animation would last that duration - or does the property only apply to Determinate transitions?

[marcelwgn]

Now another question becomes, should both Determinate and Indeterminate animations be affected by the duration? So a single loop of the Indeterminate animation would last that duration - or does the property only apply to Determinate transitions?

That's a good question. Maybe it should affect both animations as some form of "speed multiplier"? After all, we wouldn't actually say "Animation should take x seconds" but rather, "animation is speed up by a factor of 2".

[mdtauk]

Now another question becomes, should both Determinate and Indeterminate animations be affected by the duration? So a single loop of the Indeterminate animation would last that duration - or does the property only apply to Determinate transitions?

That's a good question. Maybe it should affect both animations as some form of "speed multiplier"? After all, we wouldn't actually say "Animation should take x seconds" but rather, "animation is speed up by a factor of 2".

Why wouldn't you want the animation to last X seconds? I know the Lottie animations can be more precise and defined, but with Xaml storyboards, you do define in milliseconds the length of the duration of a transition.

A speed multiplier is cleaner in adjusting the keyframes of the Lottie, but it is harder for the developer to have control when an animation is used in this way, for a control, compared to an illustration or more decorative, less functional element.

[marcelwgn]

Why wouldn't you want the animation to last X seconds? I know the Lottie animations can be more precise and defined, but with Xaml storyboards, you do define in milliseconds the length of the duration of a transition.

The question is what is the duration refering to. From 0 to 100 for determinate? Or filling the entire control? What is the duration for indeterminate referring to, especially if that does not line up with the duration for the determinate animation? I think a speed multiplier is more intuitive here to implement and use. After all, the animation for determinate state changes takes time depending on the difference of values being animated.

[mdtauk]

There is both a Duration and a Playback Rate property on the control itself.

---

Why wouldn't you want the animation to last X seconds? I know the Lottie animations can be more precise and defined, but with Xaml storyboards, you do define in milliseconds the length of the duration of a transition.

The question is what is the duration refering to. From 0 to 100 for determinate? Or filling the entire control? What is the duration for indeterminate referring to, especially if that does not line up with the duration for the determinate animation? I think a speed multiplier is more intuitive here to implement and use. After all, the animation for determinate state changes takes time depending on the difference of values being animated.

I think I would prefer there to be a Duration in Milliseconds, and the maths required to quantize the keyframes of the animation is handled by the Lottie Animation Control. So you could set the duration for the transition from one keyframe to another, then it plays those frames.

This may not be possible of course, and if not, then a speed multiplier would also be useful.
How you do that will be interesting.

Do you do it like a playback speed? 0.25 - quarter speed | 1.5 - faster speed etc?

Does the duration/speed apply to all animations, or does it only apply to the currently playing set of frames? Is there a single duration/speed for the control which would have to be changed when the animation changes?

Is this how the playing backwards could work? Should you be able to specify a starting frame, and an ending frame - and if the first is lower than the higher, it knows it should play backwards?

[marcelwgn]

There is both a Duration and a Playback Rate property on the control itself.

Yes there is, but from what I can see, we would need to do some calculations in the background to adjust for the fact that going from 0 to 10 doesn't take as long as 0 to 100 if the duration becomes something that you can set on the progressring. But I haven't worked with the animated visual player before, so take that statement with a grain of salt.

Do you do it like a playback speed? 0.25 - quarter speed | 1.5 - faster speed etc?

Yes, exactly. Setting it to 0.5 would make it play at half the speed, setting it to 2 would make it play with twice the speed.

Does the duration/speed apply to all animations, or does it only apply to the currently playing set of frames? Is there a single duration/speed for the control which would have to be changed when the animation changes?

The speed applies to the current animated visual player, so they would apply to any animation played with that. This doesn't mean though that we couldn't have two separate speeds/durations, one for determinate, one for indeterminate.

Is this how the playing backwards could work? Should you be able to specify a starting frame, and an ending frame - and if the first is lower than the higher, it knows it should play backwards?

Well yes but also no. AnimatedVisualPlayer allows playing backwards by setting the playback speed below 0. When specifying to animate from point A to point B with A>B, the AnimatedVisualPlayer would animate from A to end and animate from 0 to B. That is also what is causing the bug this PR fixes.

[ranjeshj]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).