Add ProgressRing

[Splitwirez]

What does the pull request do?

Adds the bagel-shaped ProgressRing control to Avalonia, as seen in WinUI.

...wait, were they supposed to be gluten-free?

What is the current behavior?

Avalonia has progress-indicating controls in baguette shape, but not bagel shape.

What is the updated/expected behavior with this PR?

A bagel-shaped progress-indicating control called ProgressRing is now available for use in Avalonia. How many different ways do you need me to spell it out? lol

How was the solution implemented (if it's not obvious)?

WinUI ProgressRing control is done via Lottie animations
"But could it have been done without Lottie?"
Challenge accepted >:3
?????
Profit

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

Breaking changes

None...?

Obsoletions / Deprecations

None

Fixed issues

N/A, the matter was raised in a Discussion post, not an Issue post

[Takoooooo]

I would like to mention what dragging window by the titlebar on windows would stop the animation
#4551

[Takoooooo]

Also, i would suggest making more specific converters.

At this moment you already know whether your progressring is indeterminate or not, so no additional checks and more optimized code. Also, I'm not sure if this possible but I suggest to pre-create those geometries and only bind mutable values I assume you could do that in styles.

[Splitwirez]

Also, i would suggest making more specific converters.
At this moment you already know whether your progressring is indeterminate or not, so no additional checks and more optimized code. Also, I'm not sure if this possible but I suggest to pre-create those geometries and only bind mutable values I assume you could do that in styles.

Yeah @maxkatz6 and I had a nice discussion about that on Discord last night...I think a better plan for that is starting to take shape.

[maxkatz6]

If this property was added only to simplify templating, it makes sense to move it to inner property with relevant name.
See https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/ProgressBar.cs#L151
So it's it will be like "TemplateProperties.ValueAngle"

[maxkatz6]

Meaning that developers shouldn't try to use it elsewhere

[Splitwirez]

Sorry for the slow movement on this...currently having some trouble with git stuff.

For now, though...by pure coincidence, a friend of mine happened to raise an intriguing point on Discord:

I bring this up because the way I've currently implemented this...isn't exactly able to produce the "slice of a pie" shape shown in the example image:

Sure, this is of no consequence for the Fluent theme...but assuming all themes will be that way wouldn't be very lookless of us, now would it?

[robloo]

I think the progress clock or filled progress ring is a good idea. Actually, I would argue the "progress ring" is a special case of the "progress clock" where the thickness of the "slice" is reduced to only the edge.

To achieve this correctly I think you need another shape. Just like a rectangle is the two-dimensional equivalent of a line, a sector is the two-dimensional equivalent of an arc. Adding a sector shape would allow you to achieve the "progress clock" look using the same math (angle calculation) as for the ring.

That said, sometimes you want a 'hollow' donut shape so I'll need to check if there is a good/established way to set an inside and outside diameter of a sector.

I also looked in more detail at the Arc shape. Most arcs don't specify both a start and stop angle. Instead they specify the start and then a +/- sweep angle. I think it would be a good idea to change this for convention.

• https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.arcsegment?view=net-5.0
• https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/graphics/skiasharp/curves/arcs
• https://developer.android.com/reference/android/graphics/drawable/shapes/ArcShape
• https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.media.arcsegment?view=winrt-20348

[Takoooooo]

Also, this could be useful for you
https://github.com/PieroCastillo/Aura.UI/tree/master/src/Aura.UI/Controls/ProgressRing

[Takoooooo]

I will close that PR, i tried to make it work with a master, but sadly it doesn't work correctly, but even original implementation consumes around ~300mb of memory on my PC(memory consumption jumps from 200mb to 500mb), Splitwirez will not be able to update this PR because he has deleted the branch so I think we can close that PR

[maxkatz6]

I wonder if majority of memory usages comes from this part, which is executed each animation tick
https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Shapes/Arc.cs#L81-L91

It might make sense to create something like FluentProgressRingPresenter in Fluent project which will render specific ring animation directly to the context without animations. Similarly with Default theme. In this way it still will be possible to change progress ring template and build-in implementation will work nicely (should).

[Splitwirez]

I wonder if majority of memory usages comes from this part, which is executed each animation tick https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Shapes/Arc.cs#L81-L91

It might make sense to create something like FluentProgressRingPresenter in Fluent project which will render specific ring animation directly to the context without animations. Similarly with Default theme. In this way it still will be possible to change progress ring template and build-in implementation will work nicely (should).

...if the StreamGeometry itself is the culprit, then...how would that even help?

[maxkatz6]

At least we don't need to copy geometry to apply transforms
https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Shapes/Shape.cs#L106

Also rotation can be done with a transform and not with recalculating whole geometry.
I assume right now we on each animation tick we recreate geometry with new Offset, then with new Sweep, and copy all of this on Render to apply transforms.
Although it still won't be perfect solution. Not to mention how more complex it is.