This feature would add RadialGradientBrush to UWP XAML.
The Composition team has recently added radial gradient brush capability to Windows for XAML to leverage. RadialGradientBrush is a popular and enduring request that will delight veteran XAML customers. There exists RadialGradientBrush for WPF, however many core properties such as the transform property and animation are not supported. Additionally, design research indicates a resurgence of radial gradient use in applications targeting communication, social, and recreational functions.
| # | Feature | Priority |
|:-:|:--|:-:|
| 1 | Able to customize the number of stops on the gradient | Must |
| 2 | Able to customize the color of each stop | Must |
| 3 | Able to set gradient and ellipse origin | Must |
| 4 | Support for absolute and relative mapping modes | Must |
| 5 | Able to change color space of interpolation | Must |
| 6 | WPF, Silverlight, and C++/WinRT compatibility (XAML and Visual) to enable leveraging of existing assets. | Must |
| 7 | AlphaMode modifier to support natural transparency blending | Should |
| 8 | Able to animate the stops and stop colors with Storyboard support | Should |
[x] PM: docs.microsoft.com updates ready
[x] Dev: feature previously shipped in a prerelease NuGet package
@SavoySchuler we added one to the Windows Community Toolkit the other year; however, we don't support all the needed scenarios.
Things missing from your requirements list:
Thanks, @michael-hawker, I have updated the Functional Requirements list with these bullets! Please let me know if you agree or disagree with the priorities I assigned to them - are either of the Should's worth gating a release for?
@SavoySchuler thanks! Think the only thing is for the WPF compatibility, if it's not done upfront then changing syntax can be difficult after an initial release, so it's more of a note to make sure to not deviate too far from the existing property names, enum value names, or default values.
@michael-hawker The one added to the Windows Community Toolkit isn't compatible with C++/WinRT. There's also a bug of it.
@Berrysoft yes good call. That's one of the scenarios we don't cover as the toolkit is mostly C#. We've since started adding more support for some things in C++, but it's a good call out that by adding it to WinUI it'll work for both. :)
Thanks, @michael-hawker and @Berrysoft, I have updated the proposal with those details and upgraded the priority to "Must" for that feature.
Please feel encouraged to continue high-level discussion here on the proposal. The associated Pull Request is available for more detailed discussion of the APIs.
I've had a full plate recently and I want to make sure this proposal keeps moving forward, so I will be handing #266 over @jesbis. He will be the PM owner, so be sure to @ him if you have any questions or ideas! 馃槉
Welcome @jesbis! If you have any questions or want to sync, let me know. I wrote the initial stop-gap version that we put in the Windows Community Toolkit.
馃 For History, Linking to completed WPF Parity issues #2180 #2193
Most helpful comment
@Berrysoft yes good call. That's one of the scenarios we don't cover as the toolkit is mostly C#. We've since started adding more support for some things in C++, but it's a good call out that by adding it to WinUI it'll work for both. :)