Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# Markup WinAppSDK Performance Improvements #18665

Closed
mikernet opened this issue Nov 2, 2024 · 2 comments
Closed

C# Markup WinAppSDK Performance Improvements #18665

mikernet opened this issue Nov 2, 2024 · 2 comments
Labels
difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. kind/enhancement New feature or request triage/untriaged Indicates an issue requires triaging or verification

Comments

@mikernet
Copy link
Contributor

mikernet commented Nov 2, 2024

UDPATE: It appears that the DirectXaml APIs are not available in WinAppSDK. Will update this issue once I have some info on possibly getting them exposed. Didn't realize the docs below were only for UWP (related microsoft-ui-xaml issue I opened).
 

What would you like to be added

Due to the way WinRT works, building up the UI programmatically is considerably less performant than when it is done with the XAML compiler. This is slightly problematic for C# markup running on WinAppSDK as currently written.

Luckily, there are high-performance XamlDirect APIs intended specifically to enable this scenario (that link has a lot of useful info in it, so have a look there), but C# Markup is currently not using them:

XamlDirect is purpose built for middleware that predominantly use imperative APIs to create UI instead of markup. With XamlDirect APIs, you can achieve performance parity with the XAML parser even when creating UI imperatively in code.

XamlDirect APIs can be used side-by-side with traditional APIs and take advantage of the pay for play performance improvements.

Ideally, C# markup would use XamlDirect to build the whole object graph from start to end, but as it is currently designed, that might be challenging to do everywhere (i.e. because you call new Button() ctors directly to create buttons, for example). That said, there are still many places where the benefits of XamlDirect could be utilized to improve performance. One example is in all the property setter methods:

#if !HAS_UNO
private static readonly IXamlDirect _xamlDirect = XamlDirect.GetDefault();
#endif

public static T Content<T>(this T element, object content) where T : ContentControl
{
#if HAS_UNO
    element.Content = content;
#else
    var xdo = _xamlDirect.GetXamlDirectObject(element);
    _xamlDirect.SetObjectProperty(xdo, XamlPropertyIndex.ContentControl_Content, content);
#endif

    return element;
}

Why is this needed

To bring C# Markup closer to parity with compiled XAML performance.

For which platform

Windows (WinAppSDK)

Anything else we need to know?

No response

@mikernet mikernet added difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. kind/enhancement New feature or request triage/untriaged Indicates an issue requires triaging or verification labels Nov 2, 2024
@mikernet
Copy link
Contributor Author

mikernet commented Nov 2, 2024

I would be willing to do some of this work if desired, but I can't find where you have C# markup code. Is it private?

@mikernet
Copy link
Contributor Author

mikernet commented Nov 3, 2024

Given the update above I am going to close this. My experience with microsoft-ui-xaml issues makes me sense that the likelihood of having XamlDirect APIs exposed for WinAppSDK is very close to nil so I won't pollute the repo here with this open issue.

If there is an update to the linked microsoft-ui-xaml issue with promising news then I will re-open this issue.

@mikernet mikernet closed this as completed Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. kind/enhancement New feature or request triage/untriaged Indicates an issue requires triaging or verification
Projects
None yet
Development

No branches or pull requests

1 participant