WinUI 3 Performance: A Leap Forward · microsoft microsoft-ui-xaml · Discussion #11096

These measurements are from the WinUI portion of the FE launch. The approach here is we do what we can from framework side, and obv other teams in Windows also investigated and been doing work to improve overall launch perf, we connect/collaborate frequently to make sure the improvements will be end-to-end. It's a long-term commitment for fundamentals and quality. I hope this shows at least we are listening and trying to make a change based off of feedback. :)

@beth-panx so you don't know the answer to my question. It would be nice if the next update regarding this topic would contain some real use case scenarios so we can all make an idea about the actual performance improvements. Thanks!

Personal experience doesn't always reflect the underlying performance of the framework, especially at scale. If you look at objective benchmarks (like this one: https://github.com/Noemata/XamlBenchmark), WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!. This is NOT ok. The gap is even wider when compared to native Win32 apps. While it’s great to see the platform evolving, it's crucial that the community keeps holding Microsoft accountable for these performance gaps so they actually fix them, and not comfort them that everything is ok.

One of many pressing issues is stutters in WinUI apps. Just look at the Store app. Amazing looking app but filled with lags/stutters/scroll delay. Every interaction takes >1s to respond.

You can't build a WinUI app and call it smooth at the same time.

The Store app is largely using UWP, with WinUI3 to some extent

The Store app is largely using UWP, with WinUI3 to some extent

Yap. The store app and the Setting app are both UWP. You can tell by resizing the windows...they don't show blank background unlike WinUI3 apps.

they don't show blank background unlike WinUI3 apps

TIL. WinUI3 is definitely retarded.

I don't see why it's surprising. Avalonia UI shares basically no code with WinUI

If you read the blog I linked, that's the push.

As an ex-Microsoftie this was by far the most frustrating thing working with you guys, every team seemed to do their own thing. I hope you guys really push to fix that.

As an ex-Microsoftie this was by far the most frustrating thing working with you guys, every team seemed to do their own thing. I hope you guys really push to fix that.

Obligatory MSFT Organizational Charts by Manu Cornet:

The fact that the calendar view in the action center flyout is a WebView2 is perhaps the most pathetic result of this development so far.

MAUI team had to base the map control on top of Webview2, because to this day the native UWP map hasn't yet been ported.

And then we got a WinUI map control, which is a thin wrapper on top of WebView2, slow and uncapable of using offline maps. Better use Mapsui or Esri.

If I remember correctly, OneDrive even uses Qt instead of the native tech stack, while on macOS it’s built with SwiftUI. Oh, that’s unbelievable.

I’ve always liked Windows, mostly because it’s what I grew up with. Up to now, I’ve put up with File Explorer and OneDrive because Linux still lacks some of the polish. But if Microsoft doesn’t sort these two out, Linux is going to eat Windows alive in the next few years.

With code generation becoming so cheap and accessible, the bar is rising fast. If Microsoft wants to stay competitive, I really hope they prioritise fixing this.

At our company everyone uses OneDrive, and honestly, it is one of the most frustrating parts of the workflow.

I only turn it on when I need to sync or download the latest files, then I turn it off again as soon as possible because it slows the whole system down. Syncing can take ages, and the storage handling is especially painful.

I once had about 100 GB available, let it fully sync, then suddenly I could not free up space anymore. I tried deleting files, but they just went to the recycle bin, and OneDrive still could not clean things up properly because there was not enough free space. So I was basically stuck, and the only practical solution was to buy more storage.

That kind of experience is exactly why people lose trust in it. File syncing should be reliable, and invisible and fast. OneDrive is the opposite far too often.

I could say, not just oneDrive, but also make File Explorer more cloud drives connectable

Thanks, but that specific small starter example just gets to the point of creating an app in the dev environment.
When I go here https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/deploy-overview and see all of the deployment options, I get a bit stuck. Then, drilling down into various options (and using Copilot as a guide), I have yet to stumble across a straightforward way to just deploy the thing.
The "Unpackaged deployment (EXE-style)" option that copilot lists does look like an appropriate option, but I'm pretty sure I've tried that before. I was hoping maybe by now there would be a tutorial around that.

Also unless you miss the development experience of using Visual C++ 6.0 to develop ATL components, better not try to use C++/WinRT.

Do you want to deploy your app as a legacy exe (unpackaged)?
Or modern packaged msix?

It is only for a single in-house machine, so legacy exe I believe.
That said, whatever has the simpler, more streamlined process is what I'd go with.
I am definitely not interested in creating certificates.

@Listbd Just add <WindowsPackageType>None</WindowsPackageType> in your csproj file, and change Packaged to UnPackaged in your Visual Studio (Green Play button), now you can Right Click on your project and click on ReBuild.
if you need a self-contained exe which does not need any runtime/sdk, you can add following in csproj file.

<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

you can also right click on your project and click on Publish.

WinUI is built on top of WinRT, which at its core is basically COM, with ref counting all over the place.

On UWP, with .NET Native and C++/CX, the runtimes have direct support for it, thus they can even elide AddRef/Release in some flows.

On Win32 side it is no different from using ATL (with C++/WinRT, different framework, same experience), and .NET has to deal with interop as the runtime integration with WinRT isn't there.

Naturally this slows everything down, then add on top the application identity with sandboxing.

Aside performance, the cognitive load it takes to write WinUI is excruciating. The back and forth between MIDL, Reflections, COM just makes it even worse. No matter how "easy" you make it, it can't get better. This feels like unnecessary bloat forced on developers to deal with.

Wish I could write stupid simple code to build simple apps on Windows.

A major problem with WinUI 3.0 is exactly that it isn't easy at all, especially for C++ devs.

On UWP, even if deprecated, you can reach out to C++/CX, which offers a development experience on Visual Studio, similar to VB, Delphi, or to stay on C++ camp, C++ Builder and QtCreator alongside Design Studio.

Instead a couple of devs rioted, and with the backing of Microsoft management, replaced that whole experience with C++/WinRT, without any Visual Studio tooling comparable to C++/CX.

The promises of tooling made at CppCon 2017 talk, which is relatively easy to track down, were never delivered.

Nowadays those folks are enjoying Rust, on the windows-rs crate, C++/WinRT is only getting occasional bug fixes, and anyone that still buys into WinUI marketing gets to enjoy a similar experience like doing ATL with Visual C++ 6.0 back in 2000.

If the team wants to win back those of us that left, are only around to explain the reality behind the marketing to newcomers, they need to catch up quite a bit, not only blog posts.

WinUI is built on top of WinRT, which at its core is basically COM, with ref counting all over the place.

Thanks for the helpful descriptions. As one coming from C++/MFC/Win32, the proliferation of modern runtimes and APIs is quite confusing. It all seems one big mess.

Windows doesn't make it easy for us to develop Windows apps.

• C++/WinRT + UWP.
• C++/CX + UWP.
• C++/WinRT + WinAppSdk
• C++/CX + WinAppSdk (Invalid, CX got deprecated before WinAppSdk)

Links within the docs just point to unrelated development paradigms. Some docs were written at the time of UWP were simply ported to WinAppSdk with all wrong links. This may not be an issue in all cases but behavioral differences between the APIs of the two paradigms have been diverging, and WinAppSdk requires extra steps in some cases. Btw, XAML in UWP is not the XAML in WinAppSdk WinUI, but they are still just "XAML".

Number 2 is important. Performance testing should be done on 2010-era hardware and HDDs. Part of the problem today sprang, paradoxically, from SSDs, faster CPUs, and abundant RAM: faster hardware led to practices where efficiency became less of a concern, since sluggishness would be masked.

Little by little, slow code ate away the hardware gains, and we have got a situation today where applications used to open faster on XP over two decades ago.

Testing with a machine with minimum requirement for Windows 11 should be enough. And yes, testing should be done on integrated graphics.

Number 2 is important. Performance testing should be done on 2010-era hardware and HDDs. Part of the problem today sprang, paradoxically, from SSDs, faster CPUs, and abundant RAM: faster hardware led to practices where efficiency became less of a concern, since sluggishness would be masked.

Little by little, slow code ate away the hardware gains, and we have got a situation today where applications used to open faster on XP over two decades ago.

You've hit the nail on the head. HDD is a particularly important point, and I've updated my comment.

Testing with a machine with minimum requirement for Windows 11 should be enough. And yes, testing should be done on integrated graphics.

In IoT scenarios, many configuration requirements and restrictions have been removed in Windows 11. Therefore, older configurations still need to be considered.

Testing with a machine with minimum requirement for Windows 11 should be enough. And yes, testing should be done on integrated graphics.

Also Windows 10. For example, on my Windows 10 22H2 OS, I have still this issue : #10092 (30 FPS instead of 60 FPS)

Python specifically you will need to use pyinstaller and run as a separate process and then ideally use RPC via IPC (NamedPipes). For my Tauri app, since my python app is a server, I use REST APIs instead of RPC via NamedPipes.

For rust, use FFI / PInvoke.

Qt seems a better option in that scenario

After killing C++/CX and replacing it with C++/WinRT there was never a demo at BUILD with C++, because the audience would disconnect the moment they would see manually editing of IDL files and moving around generated code.

moving around generated code

Never had a moment of needing to do so.

Only if midl command line compiler magically started to understand Visual Studio projects for C++/WinRT.

@pjmlp If you mean cppwinrt compiler which translate .idl files to winmd files (and generates implementation templates), then I think visual studio has a first class support for them already.

I have a bigger dream that all Microsoft Windows apps and OS components were native... starting from the awful New Outlook

The New Outlook must be publicly announced as a sad mistake, killed, buried and forgotten.