Refactored Uwp.UI visual extensions

[Sergio0694]

PR Type

What kind of change does this PR introduce?

• Refactoring (with public API breaking changes)
• Optimizations

What is the current behavior?

There are two things I noticed in the VisualExtensions class:

1. The class contains the ToVector2/3/4 and ToQuaternion extension methods, which actually target string. Since these types are not really tied to Visual, and also because these extensions are for string, they should be in a StringExtensions type.
2. There's a whole lot of visual extensions, like SetOffset, SetScale etc. that go back and forth to an attached property that stores the value, which then has a handler that simply sets that value in the underlying visual. This adds a ton of overhead due to the multiple indirections and handler invocations, going through the DependencyProperty backend, etc.. Since we saw that attached properties don't actually need to have a backing property in order to work in XAML (see TitleBarExtensions), we can just refactor all of these to simply act as a proxy to the Visual.Foo properties for the input element. This would make them more efficient and also simpler to implement. It would also remove issues where a property of a visual is changed outside of the extension, so the stored property becomes out of sync with the underlying visual.

What is the new behavior?

Applied both fixes mentioned above.

Also optimized the Vector2/3/4 and Quaternion parsing extensions:

• No longer rely on exceptions for control flow, completely ditch try/catch and re-throwing
• Switched to throw helper pattern when throwing exceptions (and only one per method)
• Added non-allocating path when the input text only contains a single number

Also adjusted the ToQuaternion extension to properly match the Quaternion constructor that it has.
Specifically, there is no constructor that only takes a single float, so the parsing should respect that.

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. Link:
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• New major technical changes in the toolkit have or will be added to the Wiki e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

[ghost]

Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

I was just thinking, now that we don't have the explicit registrations, does that mean that bindings won't work with these anymore to update the value???

Looking at it now, I think that's my only concern.

[Sergio0694]

Yup, just checked as well, this change makes the properties only work with either {x:Bind} or a static assignment from XAML, but both old bindings and eg. setters in a visual state don't work (I guess the same applies to the title bar extensions too then). Do you want me to reintroduce the properties to keep the support in these scenarios? 🤔

[michael-hawker]

Yeah, I'm not sure if anyone would have been updating these (at least maybe with a VSM) to do some basic options on visuals. Though I know our new animations package provides the ability to make more enriched scenarios, these are in more of a base package helper. So I think supporting more rich expressiveness with them would be important.

Can we kind of mash both worlds together or do we have to keep a backing field effectively to support that?

[Sergio0694]

The main issue is that all dynamic XAML features such as classic bindings, visual state setters, etc. all just try to match for a DependencyProperty with the right name for whatever attached property is being used, despite the various getter/setter methods being available. So not really seeing a way to make those work without reintroducing those backing properties unfortunately. We can maybe reduce the overhead just a bit by tweaking the code, removing those unnecessary designer checks etc., but as things stand I don't think we can avoid reintroducing the properties themselves if we want to support these other scenarios 😕

EDIT: as per conversation above, rebased and removed those refactoring for now.