Allow GradientBrush's GradientStops to be unordered

[dbriard]

Is your feature request related to a problem? Please describe.

Currently we have to manually sort the GradientStops by offset in order to have the correct rendering, while in WPF the gradient stop collection can be in any order, and is automatically sorted during the rendering.

Describe the solution you'd like

I would like to add GradientStop in any order, and have the correct rendering. Order should not matter.

Describe alternatives you've considered

No response

Additional context

Or may be it is a bug?

[timunie]

Sorting adds some overhead. Is there a real use case where we can't expect the devs to order them on their own?

[Gillibald]

Sorting adds some overhead. Is there a real use case where we can't expect the devs to order them on their own?

Sorting can be done at compile time. So in most cases, this should not impact performance.

[dbriard]

Sorting adds some overhead. Is there a real use case where we can't expect the devs to order them on their own?

I understand but that's a bit weird that this do not work like WPF or UWP.
Sometime to flip a gradient, I just copy/paste and switch the offsets.

My use case is porting a GradientBrushEditor control that I used in WPF to Avalonia.

One idea, may a as Gilibald suggested, sort the stops declared in XAML at compile time, and only dynamically sort Brushes created from Code? Generally there is no many stops, so the overhead should be limited.

[kekekeks]

Is there a real use case where we can't expect the devs to order them on their own?

That's WPF behavior, actually. We automatically sort gradient stops before passing those to Avalonia in XPF.