Optimize DP setter codegen for Color, CornerRadius, and Thickness on WinAppSDK#809
Open
Sergio0694 wants to merge 4 commits into
Open
Optimize DP setter codegen for Color, CornerRadius, and Thickness on WinAppSDK#809Sergio0694 wants to merge 4 commits into
Sergio0694 wants to merge 4 commits into
Conversation
Introduce a 'HasXamlBindingHelperMethod' helper that resolves the WinAppSDK 'Microsoft.UI.Xaml.Markup.XamlBindingHelper' type from the current 'Compilation' and verifies that a given static 'SetPropertyFrom*' method exists with the expected '(object, DependencyProperty, T)' signature. This unblocks gating optimized codegen on the availability of newer 'XamlBindingHelper' overloads that were added in recent WinAppSDK versions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Extend the optimized 'XamlBindingHelper.SetPropertyFrom*' codegen path to also cover `Color`, `CornerRadius`, and `Thickness` property types when targeting WinAppSDK. The corresponding 'SetPropertyFromColor', 'SetPropertyFromCornerRadius', and 'SetPropertyFromThickness' static methods on 'Microsoft.UI.Xaml.Markup.XamlBindingHelper' were added in WinAppSDK 1.6, and have no equivalent on the UWP 'Windows.UI.Xaml.Markup.XamlBindingHelper'. To avoid breaking codegen when consumers target older WinAppSDK versions, 'GetXamlBindingHelperSetMethodName' now takes the current 'Compilation' and 'useWindowsUIXaml' flag and uses 'HasXamlBindingHelperMethod' to opt in to the new methods only when they actually exist with the expected signature. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Consolidate repetitive type checks into ReadOnlySpan<(string,string)> loops to map well-known types to their corresponding XamlBindingHelper SetPropertyFrom* methods. Add an early return when useWindowsUIXaml is false to avoid probing WinAppSDK-only APIs on UWP. Combine type name checks with HasXamlBindingHelperMethod calls for WinAppSDK-only types. Also update the call site to use named arguments (typeSymbol, useWindowsUIXaml, compilation) for clarity.
…hable The early-return guard introduced in the previous commit used '!useWindowsUIXaml', which short-circuited on WinAppSDK and skipped the new 'SetPropertyFromColor', 'SetPropertyFromCornerRadius', and 'SetPropertyFromThickness' probes entirely (the opposite of the intent stated in the inline comment, and of the actual feature this code is meant to enable). Flip the condition to 'useWindowsUIXaml' so we bail out on UWP (which never gets these methods) and continue probing on WinAppSDK. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the previous
XamlBindingHelper-based DP setter optimizations.The latest version of WinAppSDK exposes three new static methods on
Microsoft.UI.Xaml.Markup.XamlBindingHelper:SetPropertyFromColor(object, DependencyProperty, Windows.UI.Color)SetPropertyFromCornerRadius(object, DependencyProperty, Microsoft.UI.Xaml.CornerRadius)SetPropertyFromThickness(object, DependencyProperty, Microsoft.UI.Xaml.Thickness)These extend the optimized setter path the generator already uses for other well-known WinRT-projected types, but they (1) only exist on WinAppSDK (the UWP
Windows.UI.Xaml.Markup.XamlBindingHelperhas no equivalent) and (2) were only added in a recent WinAppSDK release. Consumers on older WinAppSDK versions must therefore not get codegen that calls them.What changed
Execute.GetXamlBindingHelperSetMethodNamenow takes the currentCompilationand theuseWindowsUIXamlflag so it can probe the resolvedXamlBindingHelpertype for the new methods.Execute.HasXamlBindingHelperMethodhelper resolvesMicrosoft.UI.Xaml.Markup.XamlBindingHelper(viaWellKnownTypeNames.XamlBindingHelper(useWindowsUIXaml: false)) and verifies the fullstatic void Method(object, DependencyProperty, T)shape, whereTmatches a caller-supplied metadata name. The strict signature check guards against any future overload with the same name but a different shape.ReadOnlySpan<(string, string)>literals — one for the methods available on both UWP and WinAppSDK, and one for the new WinAppSDK-only methods. UWP short-circuits before the second loop, so noGetTypeByMetadataNamework happens on the UWP path.DependencyPropertyGenerator.csflowsuseWindowsUIXamlandcontext.SemanticModel.Compilationto the helper using named arguments.Correctness / incremental notes
useWindowsUIXaml == true) is left completely untouched — the new code is gated behind!useWindowsUIXaml, and existing snapshot tests (which target UWP) are unaffected.ForAttributeWithMetadataNameAndOptionstransform, which already takes a non-equatableGeneratorAttributeSyntaxContextand produces equatable output. The resulting method name flows through the existing equatableDependencyPropertyInfo.XamlBindingHelperSetMethodNamestring, so downstream output correctly invalidates when a project upgrades its WinAppSDK reference.Compilation.GetTypeByMetadataNameis internally cached, and the probe only runs after the property type already matches one of the three new metadata names, so the per-property overhead is negligible.Tests
No new tests are added: the new behavior depends on whether the host compilation references a WinAppSDK version that exposes these methods, and that cannot easily be toggled inside the existing snapshot test infrastructure. The change is purely additive on the WinAppSDK code path and leaves UWP/
useWindowsUIXaml == truecodegen unchanged, so existing test assertions continue to hold.