WinAppSDK 1.6 Plans

[codendone]

Planned work for Windows App SDK 1.6 is largely in four focus areas, with the main examples listed for each focus area:

• Quality:

  • Address top issues, including some top control issues, WinAppSDK installer

• Performance:

  • C# Native AOT support, fix some general performance issues

• Better experience:

  • Better TitleBar and tab dragging
  • Better developer experience (such as IntelliSense and x:Bind improvements)

• Progressing in 1.6, but not finishing until 1.7+:

  • TableView, inking controls, and cross-process Islands
  • Smooth app resize

Please use this discussion to provide feedback on these plans, or to provide feedback and up-votes on the next features and issues we should prioritize.

[Natriss]

What is the price tag on the maps control?
I remember something vaguely about costs of x amount tiles rendered.
Is there a way to cap it?
Could you elaborate on that?

[Natriss]

It's still a control in WinUI 3.
Idc if it's native or not. I only care about the price we as developer have to pay.
It's so vague on when you get charged and knowing there is no limit that we can set is a bit scary.

[Natriss]

@codendone could you elaborate on this?

[codendone]

I think you've already found this, but for the benefit of others:

• Pricing - Azure Maps

There isn't a limit, as far as I've heard, but I'll update if I find more.

[Natriss]

Thanks @codendone.
What does MS mean with Base Map Tiles - 5000 free.
What is a tile. Is that a piece of the world map? The world map itself? How big is a tile?
It's also just a fixed number. Does this mean we can only have 5000 free forever or is that renewed daily, weekly, monthly or annually?

[HEIC-to-JPEG-Dev]

The tiles are 512 x 512 (or 256 x 256) - the content of which depends on what you want the map to display, satellite images, road, etc. So your screen view is divided into a tiles of 256 x 256 and each one you populate, costs you 1 tile. Tile counts are renewed each month

[horaciodiez]

ChatGpt wrote:

Dear WinAppSDK Team,

I hope this message finds you well. As I explore the capabilities of WinAppSDK, I've identified a usability concern related to ContentDialogs, especially when utilized for data entry. Due to the fixed positioning, the inability to drag and reposition these dialogs limits their flexibility and prevents users from viewing the content beneath them.
Introducing the option to move ContentDialogs or considering a Dialog-like Window would greatly enhance user experience and address this specific limitation.
I've noticed that even some Blazor libraries already offer similar controls for the web.
I'm eager to know if there are plans or considerations for incorporating this feature in future WinAppSDK releases. Thank you for your time and dedication to the developer community.

Best regards,

Thank You! 😄

[codendone]

Thanks for your feedback, @horaciodiez. Yes, improved dialog capabilities, including those you mention, is something we'd like to make easier and maybe even default.

[charlesroddie]

C# Native AOT support, fix some general performance issues

Finally with AOT support we can move from UWP. For us the faster this can come, even in a beta version, the better, as maintaining UWP is preventing us from moving to dotnet8.

[HEIC-to-JPEG-Dev]

I'm going to say no to that hypothasis because WinUI by default does not use the AppContainer. Not using the AppContainer makes WinRT Disk IO a factor of 10 times slower than UWP. Switch on the AppContainer and WinRT IO performs as UWP, but you lose all the .net FileInfo etc and the app is bound by its container.

[lhak]

I would like to see the following experimental features being promoted to stable:

ContentExternalOutputLink class: To enable blending of content with swap chains using directcomposition interop.
DisplayInformation (the dpi related methods): Needed to provide initial window sizing as the XamlRoot dpi methods are not enabled until the window is shown. Alternatively another way to set window sizing in a dpi independent way.

Alternatively, a way to enable experimental features in stable releases would also be beneficial, as the experimental releases lack bugfixes compared to the stable releases.

[dongle-the-gadget]

You can shoehorn the experimental WinMD files into stable (Files uses this). ContentExternalOutputLink is implemented in stable, but you just aren't able to access it without raw ABI or an experimental WinMD file since its metadata has been stripped from the stable WinMD.

[kmgallahan]

On the documentation side:

• Please fix the broken API search function, it has not worked since WASDK had its docs split out from WinUI 2. And by "broken" I mean no results are ever returned: Search isn't working MicrosoftDocs/winapps-winrt-api#6.
• Please update all Visual Studio F1 (go to API docs) to direct to the WASDK API docs. Currently, some go to WASDK (e.g. Page and Grid) and others to WinUI 2 (e.g. NavigationView and InfoBar).
• Please add additional documentation for the available lightweight styles found in Generic.xaml. Only a few are mentioned such as in the NavigationView Guidelines, while the majority require inspecting Generic.xaml to figure out what is available.

[HEIC-to-JPEG-Dev]

Please update the WinAppSDK repository documents - the links still point to version 1.1 as the main roadmap

[duncanmacmichael]

Happy to update the version references - can you point to where you saw any documents still talking about 1.1? The roadmap page currently refers to 1.5 (will be updated soon to 1.6), and none of the other pages in the Docs folder of the repo refer to 1.1, so I'm not sure which documents you're talking about here.

[HEIC-to-JPEG-Dev]

From the WinAppSDK home page, there is a link under Helpful Links - More details about the Windows App SDK

On th epage that opens, there is a section called More Documentation - the link Roadmap + vote on features is where it goes to the wrong roadmap page

[duncanmacmichael]

Ah, that's what you're referring to, like the comment below this one. I went ahead and removed references to that site since we don't plan on using it or updating it anymore, and have redirected to the roadmap page within this repo instead (which we plan on updating for 1.6 soon once we're done processing feedback and finish planning). Thanks!

[james1301]

Why did you stop using this product board: https://portal.productboard.com/winappsdk/1-windows-app-sdk/tabs/2-planned?

This was quite clear what was going on and offered voting which allows the most popular options to be visible. Is there anything else like this I should be looking at?

I would like to try to make use of some of this through XAML Islands for WPF, in an easy way that works well. Not sure what this will look like at present.

Going all in on using Win UI 3: Validation on editors and this issue: microsoft/microsoft-ui-xaml#6299

[ChaimCL]

If I remember correctly, the message was that the person responsible for creating the section left the team and he used a private account to create it, so it was abandoned.

[james1301]

I see, recreating it or something might be good 🙂. And removing links to the old one. It just seems a good way to get numbers on the features that are in demand. Especially now a lot of the fundamental stuff is there now.

[duncanmacmichael]

Thanks for asking this! That site was before my time working on this project so I had to go digging a little bit, and it turns out @ChaimCL is correct. We have no plans to update the site, so I've gone ahead and removed links to it and redirected to the roadmap page within this repo instead (which we plan on updating for 1.6 soon once we've processed all the feedback and are finished planning).

[christosk92]

Any updates on #3305 ?

[kmgallahan]

Please resolve [BUG] XamlTypeInfo.g.cs generates invalid code for types with required or init properties if possible.

I'm sure this issue will give every WinUI developer a headache at some point. ~I just lost a fair amount of time trying to figure out why my builds were failing.

[kmgallahan]

Please stop automatically adding this stuff to csproj files every time a XAML file is added to a project, it hasn't been necessary for a while now and is just garbage to clean up:

    <ItemGroup>
      <None Remove="asdf.xaml" />
    </ItemGroup>

    <ItemGroup>
      <Page Update="asdf.xaml">
        <XamlRuntime>$(DefaultXamlRuntime)</XamlRuntime>
      </Page>
    </ItemGroup>

[MartyIX]

Performance:

* C# Native AOT support, fix some general performance issues

@codendone Is there a plan to improve general performance in the sense that MAUI applications on Windows will be faster? Right now, in the debug mode, I can see that simple WinRT calls take several milliseconds which adds up quickly.

[DarranRowe]

When you state "in the debug mode" do you mean that your application is built for the debug configuration or do you mean that your application is built for the release configuration and you have the debugger attached to that?
If your application is built for the debug configuration then it is difficult to reason about performance in general. The machine code emitted by the C++ backend or the IL emitted by the C# compiler do not optimise much and this can result in a lot of lost performance. It can be bad enough that this debug code can dominate the performance loss.
To give a little example of what I mean, suppose we have the following click handler for a button. This is timing how long Windows.Foundation.Uri.AbsoluteUri takes to call.

    void MainWindow::Click_Click(winrt::IInspectable const &, winrt::RoutedEventArgs const &)
    {
        LARGE_INTEGER start{}, end{}, freq{};
        uint64_t total_time{};

        QueryPerformanceFrequency(&freq);
        auto uri = winrt::Windows::Foundation::Uri(L"File:///C:/Users/Darran/AppData/Local/test.txt");
        QueryPerformanceCounter(&start);
        auto text_str = uri.AbsoluteUri();
        QueryPerformanceCounter(&end);

        Uri().Text(text_str);
        total_time = ((end.QuadPart - start.QuadPart) * 1'000'000'000) / freq.QuadPart;
        auto total_time_text = std::format(L"{}ns", total_time);
        TimeTaken().Text(total_time_text);
    }

When built using the debug configuration, the times tend to group around:

when built using the release configuration, the times tend to group around:

So the debug overhead adds around half a µs to the call on average. There is more to this, but surprisingly Native AOT may actually do a lot of what you want here. Since as you may have noticed, an example of a WinRT call take microseconds or even hundreds of nanoseconds in native C++. This is the reason why .NET Native was used for UWP and why I believe Native AOT is high priority here.

Also, just in case you are thinking that I cherry picked results. Timing the call to TextBox.Text gives similar results.

For debug, the first call to it takes the longest:

But subsequent calls are much faster:

With release, the first call is much slower, but it ends up in the same region as debug:

This makes me feel that it is the WinUI library initialising and allocating something. But subsequent calls then are much faster:

The thing to note is that the debug overhead effectively doubles the time it takes for the call to take place.

So if you have specific questions about performance then first, use the release configuration times. Next, try to take .NET out of the equation. The projection and managed <-> native transitions can add a lot of time to any calls.

[jonwis]

Under the covers, C#/WinRT has to generate and cache appropriate p/invoke wrappers the first time a call is made, and then .NET has to JIT them. After that, they're fast. Using AOT and NAOT could help.

Consider using a profiling tool instead of just QPF - See https://learn.microsoft.com/visualstudio/profiling/?view=vs-2022 or https://learn.microsoft.com/windows-hardware/test/wpt/windows-performance-analyzer-common-scenarios for how to measure directly where the time goes.

[MartyIX]

Thank you for the information.

I'll try to phrase it a bit differently because my main motivation is to understand why MAUI is "slow" on Windows. I created dotnet/maui#21246 PR there that caches on MAUI's side Package.Current.InstalledLocation.Path (not too important what it is I guess). The reason why it seems beneficial is that it saves in the .NET Release mode about 10-20ms for like 4 calls of Package.Current.InstalledLocation.Path (requires interiop from .NET to Win UI 3; not sure about details).

Now, I think those calls of Package.Current.InstalledLocation.Path take too long (10 - 20ms is too long), I would expect it take no time really (with caching in .NET it's much faster).

Now, yes I should measure why those calls of Package.Current.InstalledLocation.Path are slow (I have no experience with it so far). But based on your experience: Do you expect it to be a MAUI issue, or WinRT issue or WinUI 3 issue? Or maybe phrased differently: Is it expected?

The projection and managed <-> native transitions can add a lot of time to any calls.

@DarranRowe So is it a reasonable guess that MAUI on Windows is slow because those managed <-> native transitions are slow? Is there anything that can/will be done to make it faster or is it slow because "it cannot be fundamentally faster"? I don't have any intuition here.

[DarranRowe]

First of all, Package.Current.InstalledLocation.Path is actually not a single call. Package.Current is a static property that obtains the current package. InstalledLocation is a property that then obtains a StorageFolder with the package's path. Finally, StorageFolder.Path is then another property that returns the actual path stored in a HSTRING. That is 3 WinRT calls there. Although again, the first call should be the slowest where subsequent ones should be much faster.

    void MainWindow::Click_Click(winrt::IInspectable const &, winrt::RoutedEventArgs const &)
    {
        LARGE_INTEGER start{}, end{}, freq{};

        QueryPerformanceFrequency(&freq);
        QueryPerformanceCounter(&start);
        auto path = winrt::Windows::ApplicationModel::Package::Current().InstalledLocation().Path();
        QueryPerformanceCounter(&end);

        uint64_t time_taken = ((end.QuadPart - start.QuadPart) * 1'000'000) / freq.QuadPart;
        Path().Text(path);
        auto time_taken_text = std::format(L"{}µs", time_taken);
        TimeTaken().Text(time_taken_text);
    }

From the performance that I have seen, the first access of the package path is always going to take some time. My guess is that Windows doesn't populate that information until the application accesses it for the first time, and then it caches it. Really, the best thing the application can do in this situation is to either accept that the first call is going to take >10ms for the first time accessing this information, or get out ahead and just do a dummy access of this information as the application is starting.

As a side note, it is also surprising how much time just accessing the package through Package.Current takes. You can see from the above screenshots that subsequent accesses to the installed location takes almost 400µs. However, if the package object is cached in the window in the constructor:

    MainWindow::MainWindow()
    {
        m_package = winrt::Windows::ApplicationModel::Package::Current();
    }

and we use that cached instance to access the path:

    void MainWindow::Click_Click(winrt::IInspectable const &, winrt::RoutedEventArgs const &)
    {
        LARGE_INTEGER start{}, end{}, freq{};

        QueryPerformanceFrequency(&freq);
        QueryPerformanceCounter(&start);
        auto path = m_package.InstalledLocation().Path();
        QueryPerformanceCounter(&end);

        uint64_t time_taken = ((end.QuadPart - start.QuadPart) * 1'000'000) / freq.QuadPart;
        Path().Text(path);
        auto time_taken_text = std::format(L"{}µs", time_taken);
        TimeTaken().Text(time_taken_text);
    }

The first access takes ~12ms, so I really believe that this is how Windows works and therefore the first access taking that long is expected. But subsequent accesses to the installed location are much faster:

As you may guess though, caching the StorageFolder that contains the path or the path itself ends up being the fastest. The performance hit is on the InstalledLocation call. From the StorageFolder object, it only takes around 8µs to obtain the package's install path.

So is it a reasonable guess that MAUI on Windows is slow because those managed <-> native transitions are slow? Is there anything that can/will be done to make it faster or is it slow because "it cannot be fundamentally faster"? I don't have any intuition here.

You could gain some of that intuition by comparing native timings with comparable managed timings. But the important thing is, sometimes the first call to something isn't the best call to base any performance indicators on. Windows itself doesn't seem to initialise some package related information until you attempt to access it once. As @jonwis also mentioned, the C#/WinRT projection also does a lot more work on the first call to initialise the wrappers.
In general, C# shouldn't be that much slower than C++ here. But I hope that you are not making the mistake of seeing that a single call can take a while to complete and assuming that this is the same kind of performance as the general case. I agree with @jonwis here in that you really should be properly profiling things.

--Edit--
Checking the C# performance, and it is really interesting. But the 3 calls in one line with the corresponding transitions is what really hurts here.

        private void myButton_Click(object sender, RoutedEventArgs e)
        {
            long start = Stopwatch.GetTimestamp();

            var installedPath = Windows.ApplicationModel.Package.Current.InstalledLocation.Path;
            long end = Stopwatch.GetTimestamp();

            double elapsed_time = ((end - start) * 1000000) * (1.0/Stopwatch.Frequency);
            Path.Text = installedPath;
            TimeTaken.Text = elapsed_time.ToString();
        }

Doing it this way ends up with around 5ms per call. Caching the StorageFolder removes most of that overhead.

        public MainWindow()
        {
            this.InitializeComponent();

            _cachedFolder = Windows.ApplicationModel.Package.Current.InstalledLocation;
        }

        private void myButton_Click(object sender, RoutedEventArgs e)
        {
            long start = Stopwatch.GetTimestamp();

            var installedPath = _cachedFolder.Path;
            long end = Stopwatch.GetTimestamp();

            double elapsed_time = ((end - start) * 1000000) * (1.0/Stopwatch.Frequency);
            Path.Text = installedPath;
            TimeTaken.Text = elapsed_time.ToString();
        }

        private Windows.Storage.StorageFolder _cachedFolder = null;
    }

The times in those screenshots are in µs. As you can see, caching the storage folder ends up only taking ~30µs per call regularly. The first call taking >400µs is what @jonwis was writing about in that C#/WinRT has to initialise some things on the first call. So I hope this helps with your intuition as to the overhead in the managed environment. I also believe this is something that Native AOT will help with when it becomes available.
Beyond this, the only real thing that will help is to reduce the amount of managed <-> native transitions you do. Either by caching heavily used objects, or by using P/Invoke to reduce the amount of times you have to cross over the managed/native boundary.

[HEIC-to-JPEG-Dev]

Modify the AppConatiner to allow use of WinRT disk IO and .net FileInfo at the same time. WinRT IO is 10x slower when the AppContainer is in full trust.

[MartyIX]

You are correct, the AppContainer is either on or off for the package. When off (default), WinRT IO is 10x slower but we can use the .Net FileInfo; when it's on, WinRT IO is 10x faster but we lose the .Net features.

How can one test that please? I would love to test this if it can make my MAUI app faster.

btw: There was a discussion here and I have still not found the time to measure stuff but I can see that unmanaged calls take a lot of time from my MAUI app (and not that much is happening imho).

[HEIC-to-JPEG-Dev]

Are you asking how to turn on/off the AppContainer in WinUI, or how to time your code, or what specifically is slow ?

[MartyIX]

Are you asking how to turn on/off the AppContainer in WinUI

Yes. That is my question.

[HEIC-to-JPEG-Dev]

Look at the properties of the app, there is a trust level that can be partial or full

[DarranRowe]

My opinion. I want to write app X using WinUI - WinUI is 10x slower compared to UWP - this is a WinUI problem.

If you use the technology outside of WinUI and you get the same results then it isn't a WinUI issue. Have you tried to package up a regular .NET application and see if the performance is the same when using the WinRT runtime classes?

It doesn't make it a UI framework problem if you observe the behaviour using that framework. This is especially true since anything under the Windows root namespace is completely independent of WinUI 3. This is why I have suggested multiple times to use the Feedback Hub to provide this feedback. Providing the feedback to the correct location seems a lot more productive than mentioning it in a repository of an unrelated SDK.

[HEIC-to-JPEG-Dev]

Update the Visual studio templates to use .net 8/9 - it's still on .net 6

[DarranRowe]

They have been.
At the moment, the lack of the updates for the templates in Visual Studio itself is likely coming from the Visual Studio side of things.

[HEIC-to-JPEG-Dev]

A fix in some GitHub repository doesn't help - if it's not in the tooling (e.g. Visual Studio) it effectively doesn't exits. If it's the VS teaming falling behind then it's the responsibility of the WinAppSDK team to get it published.

[DarranRowe]

Of course.
But if anyone ends up here with the same question, then they know where the updated templates are. They can also manually fix the projects too.

[HEIC-to-JPEG-Dev]

The GitHub repository is not a fix though - it requires an internal MS account to compile. There are also no instructions on what to do; we can't compile the VSIX, so I'm not sure how this helps ?
Of course we can search the internet to find out how to fix the projects, but it has been 4 months since .net 8 was released.

[DarranRowe]

so I'm not sure how this helps

I guess my use of "manually" didn't help.
Two words then. Copy, paste.

With the files being on the repository, you can copy some of the contents of the files there and paste them into your solution. You can update the .csproj, .pubxml and individual source files with any changes.

Now, the IMPORTANT point to note, I am NOT advocating that this is a solution or anything like that. I'm just stating that this is a way to get the new project template contents into a new project now.

[AndrewKeepCoding]

Smaller app folder size would be very welcomed by many devs.
#2478

[AliShahesmaeili]

Native os splash screen like UWP
#500

[SID9-HoneyBee]

Very pleased that the content on inking controls has been updated. I look forward to being able to utilize this feature in version 1.7+

[Wandtket]

Still experiencing intermittent crashes related to 9070 and possibly others when users are just interacting with the app.

Is there a way we can prevent the application from force closing completely when an error unrelated to the application is thrown? We handle all of our exceptions and store them for later research but we can't do that when the app force closes.

[jingliancui]

Official pager control?

[ghost1372]

Added in v1.5 experimental but removed from stable 🤔
Mybe return in 1.6

[jingliancui]

Yep,please,i need it, in the meantime, i wonder how you deal with the scenario in enterprise application for example need the app show pages data.

[ghost1372]

Yep,please,i need it, in the meantime, i wonder how you deal with the scenario in enterprise application for example need the app show pages data.

If you are using C# you can use a ported version from winui 3 codebase
https://github.com/WinUICommunity/WinUICommunity?tab=readme-ov-file#pagercontrol

https://github.com/marcelwgn/PagerControlPolyfill

[jingliancui]

https://learn.microsoft.com/en-us/visualstudio/deployment/installer-projects-net-core?view=vs-2022

Support installer for unpackage publish content

[Damix48]

I think that these 2 issues are very important to fix, they are in the microsoft/microsoft-ui-xaml repo:

• Resizable pointer shows up even when a window is maximized microsoft-ui-xaml#8665
• When the app is maximized, the hidden taskbar cannot be triggered. microsoft-ui-xaml#8431

[jp-weber]

For me, the missing designer is the most important feature:
Discussion: WinUI 3.0 XAML Designer. microsoft-ui-xaml#5917

[uixiu]

At least, WinUI developpers deserve a good previewer.

[WindowsNT]

It would help the new APIs like https://learn.microsoft.com/en-us/windows/ai/apis/text-recognition-api-ref could be used in a plain GPU. Very few have a NPU yet.

[harvinders]

@codendone It would be nice to see support for Native AOT for OptionalPackages. We have OptionalPackages loaded at runtime using AssemblyLoadContext.