WinUI 3 Performance: A Leap Forward #11096
Replies: 33 comments 117 replies
-
|
Glad to see WinUI 3 is not forgotten. Question, those reductions from the File Explorer launch that you measured - how much do they impact the launch itself? I assume it's not a ~40% reduction in launch time. Could you tell us, @beth-panx? |
Beta Was this translation helpful? Give feedback.
-
|
I’ve not noticed performance issues with my apps in WinUI at all. System apps, yes, file explorer top part is slow, hangs, etc. Performance issues for me are all Visual Studio Build related. |
Beta Was this translation helpful? Give feedback.
-
|
Breaking changes are fine as long as they benefit devs in the end. I don't have any issue with launch time especially with AoT enabled. I do have a issue with unresolved bugs in WinAppSDK/CsWinRT/BuildTools though. |
Beta Was this translation helpful? Give feedback.
-
|
Love this. Amazing work. Looking forward to this |
Beta Was this translation helpful? Give feedback.
-
|
What you need to do is actually use your framework across the company. Massive rewrites of everything in Windows OOB to this should be the highest possible priority in the company. |
Beta Was this translation helpful? Give feedback.
-
|
Winui should be more customizable to attract more 3rd part dev to implement |
Beta Was this translation helpful? Give feedback.
-
|
I really like this initiative, genuinely! But if Microsoft wants to make the Windows experience truly shine, the top two priorities should be rebuilding File Explorer and OneDrive from the ground up. The ripple effect those two have across the whole ecosystem is huge, and improving them would make everything else feel better too. |
Beta Was this translation helpful? Give feedback.
-
|
Glad to see the renewed focus on WinUI. The community waited a long time to see this change, and I hope dogfooding becomes part of the culture in Windows with WinUI. Are you also looking to improve File Explorer context menu perf? |
Beta Was this translation helpful? Give feedback.
-
|
(new) Outlook team take notes |
Beta Was this translation helpful? Give feedback.
-
|
Performance is a very welcome improvement. However bringing back the .NET Native and C++/CX Visual Studio development experience is also quite relevant, and feature parity with everything that is still missing from Windows Forms and WPF features. |
Beta Was this translation helpful? Give feedback.
-
|
I'd really like to dive in to WinUI. Could someone please point me to a good tutorial that focuses on deploying WinUI 3 apps. Last year I spent some time spinning something up and it was nice, until I went to deploy. It got very complicated very fast. The resources I found at the time didn't quite get me there. Thx. |
Beta Was this translation helpful? Give feedback.
-
|
Please, make it happen! |
Beta Was this translation helpful? Give feedback.
-
|
I'm glad to see Microsoft making a concerted effort, listening to the concerns of users. Still, how efficient is WinUI 3 compared to bare Win32? Is the latter approach not feasible at Microsoft any more? If we look back at the old days, Windows applications and dialogs used to open instantly. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I hope that WinUI3 can implement a declarative development paradigm to some extent, which is the unified choice of almost all modern view frameworks. |
Beta Was this translation helpful? Give feedback.
-
This is not true for my existing WinUI 2 VB projects. It's painful to patch the XAML compiler to extend language support since the XAML compiler is closed source. |
Beta Was this translation helpful? Give feedback.
-
|
Please also work on updating the UI of the bottom 3/4 of File Explorer, which still uses design elements from Windows 8/10. File Explorer needs the glow-up it deserves. |
Beta Was this translation helpful? Give feedback.
-
|
There needs to be an easy way to use WinUI in applications coded in Python and Rust. |
Beta Was this translation helpful? Give feedback.
-
|
Can you give us visual editor we used to have in the 90s and 2000s, so actual developers can easily design windows using drag&drop using latest UI tech? |
Beta Was this translation helpful? Give feedback.
-
|
WinUI 3 apps have horrible performance redrawing a window when it's being dragged around. You are clearly doing it wrong. Just go back to Win32/WinForms or WPF. |
Beta Was this translation helpful? Give feedback.
-
|
Using C++ for WinUI3 development is pretty clunky, because it leads to a lot of performance being wasted in C# apps due to CsWinRT interoperability. Plus, if you go with native C++ for development, you'll have to put up with super low development efficiency. |
Beta Was this translation helpful? Give feedback.
-
|
I have a dream that ms office apps on Windows were rewritten in WinUI. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for finally putting more work in WinUI 3. Making WinUI 3 genuinely better than choosing web is gonna help a lot in making developers actually consider using it because in its current state it's not really appealing. There's one major issue I personally have that defers me from using WinUI 3 for my own apps and that's the laggy rendering at runtime, especially the resizing and lack of sychronization with DWM is extremely disturbing and affects everything created with WinUI 3. Please have a talk with the DWM team at Microsoft! UWP performs Direct Composition synchronization using some private APIs to get super smooth solid resizing of windows, it's very solid. WinUI 3 completely lacks any communication with DWM, DWM just renders the buffers from WinUI at whatever pace it pleases and this results in an awful feeling delay when resizing a window where the rendered content lags behind the window frame. It's possible to use the private UWP APIs to sync up WinUI 2 XAML Islands with DWM via DComp, some apps like Magpie do this. It gives the exact same, solid and clean resizes and rendering sync you get for free with UWP apps and makes XAML Islands with WinUI 2 genuinely a better choice over Win32 where you don't get a thing like this. Having to manually implement DComp sync for all my WinUI 2 apps is way too time consuming to be practical for anything. I'm not gonna build any actual apps myself by doing this at the moment. WinUI 3 seriously needs DComp synchronization, if not possible on 1809 and up, it should at least be turned on at runtime on newer versions of Windows 11 whenever the DWM team decides to release an API that WinUI 3 can use to perform this, if it's not possible to make WinUI 3 sync up using the existing private APIs. Honestly these APIs shouldn't even be private, every developer should have control over how they want the compositor to treat their UI. DWM needs a lot of work to reduce how GPU and memory hungry it is and it needs more control for developers. The laggy resize is something iconic in web apps, in every web browser nowadays, resizing peels back multiple layers of rendering and windows stacked on top of each other and every Electron/PWA whatever app is affected by this. The fact that WinUI 3 feels the same when doing something as simple as changing the size of a window makes it to an end user not much different experience than a Tauri app skinned to look like WinUI 3 to be honest. As soon as WinUI 3 has DWM synchronization I will start taking it serious to use it for my software, until then I will contine focusing on QT Widgets and wxWidgets since those aren't so bad when it comes to this and I can be assured that if Windows goes down hill further I'm more assured that my project isn't tied to the operating system. Thank you very much for improving the performance! I have high hopes to see Windows get better, I seriously want the quality to be pulled back in and I've been losing hope on this platform. |
Beta Was this translation helpful? Give feedback.
-
|
An outside developer showed whats possible with Windows: https://taskslinger.net/#early-access The WinUI 3 Gallery install package has 75M(!) and over 160Megs in RAM. Navigating with the app is sluggish (on very current notebook). This is a damn demo application that does not hold or process any data! Having read about tricking with the CPU scheduler (low latency mode), I have strong doubts that the team is really moving to the right direction. It's time for a clean sheet! |
Beta Was this translation helpful? Give feedback.
-
|
You were supposed to keep developing UWP and remove the sandboxing in some way. That'd be porting WinUI to UWP. Instead, you did the opposite. Ported UWP to WinUI. I'm pretty sure we would've been in a better place so far. The decision to keep Microsoft Store still UWP by @rudyhuyn makes it all clear. Nobody can deny that it's the best (and/or only) in-house app so far that Microsoft launched for years. However, everything starts with an inititive which shows MS is acknowledged and started working on it. When and what will happen in the future? I don't know. I think the platform is good enough, but ofc like anything else it can be improved. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding Explorer, another point is that, even on 10, it feels sluggish when scrolling through big folders, such as System32. I can't remember if this began in Vista or afterwards, but certainly in XP and earlier, there used to be solid scrolling. |
Beta Was this translation helpful? Give feedback.
-
|
Really glad to see great performance improvements coming to Winui3 and that all teams are starting to work together. I really think startup times, click responsiveness, panel transitions should be the top priority here (As you are doing). But there are some things that should be really addressed, the most slow thing about windows 10 or windows 11 are the splash screens. We do have super fast nvme disks, 6ghz processors and i did not see any splash screen on windows 95 and I have to see them since windows 10. Even a simple app as Windows 11 settings app feels laggy on laptops, something as simple as a click you can feel the delay opening new panels as it just doesn't start loading until you fully release the click of the mouse. And even the new task manager feels laggy when the screen refreshes with new processes data every several seconds. I don't understand why even low end mobile phones feel much snappier than a windows laptop nowadays. |
Beta Was this translation helpful? Give feedback.
-
|
I think that's awesome, I hope you guys manage to improve performance all around. We're seeing a movement currently of building things from scratch like File Pilot and Taskslinger. Everything on those apps is made from scratch using custom, immediate mode UI frameworks. I'd like to know your thoughts about just making an immediate mode framework, no XAML, no binding, no retained state. Do you think this would be possible or would it just be throwing too much stuff away and you just can't do that? I'm asking just out of curiosity, really. It feels like UI frameworks always end up being abandoned at Microsoft because you guys find the next best thing and what ends up happening is everything gets very inconsistent and people lose trust on your frameworks. I think XAML is better than CSS, for example, but I think one of the reasons it hasn't caught up is because of the feeling you can't rely on Microsoft UI frameworks to last. Maybe you guys should go back to the basics and do a VERY simple thing, less abstraction and less stuff in the way of developers. A simple infinite loop, where you decide what's going to be drawn is the simplest UI thing I can think of. Then you should stick with that. Even if all that's impossible, I think you guys should be focusing on executable size, startup speed and performance in general. Try to eliminate as much overhead as possible, use game metrics as the default. Everything should happen on the same frame, you should target at least 16ms. That's what those softwares from scratch are doing, btw. I like the initiative and really hope things get better (and simpler) |
Beta Was this translation helpful? Give feedback.
-
|
if anyone interested, XamlOptionalChanges Spec is ready now! |
Beta Was this translation helpful? Give feedback.
-
|
Please, I just ask that you care more about developers and drastically reduce the boilerplate! Code that I can write in 15 lines using SwiftUI requires 60 lines and 3 files in WinUI / XAML! |
Beta Was this translation helpful? Give feedback.
-
|
Good news, they’re finally delivering on the promised performance improvements! Improve performance of XBF deserialization Here you can find all related commits (Perf2026 and Perf) |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
Hello WinUI Community!
Our mission is to make WinUI 3 the best native UI platform for Windows experiences and apps and performance is at the heart of that effort. Moving from WinUI 2 to WinUI 3 should always be a clear win for performance, and apps should get great results without heavy lifting.
Why Now
Pavan recently shared a blog post, in which "more fluid and responsive app interactions: Reducing interaction latency by moving core Windows experiences to the WinUI3 framework" was mentioned as part of our quality commitment. Making this a reality means delivering performance improvements at multiple levels, including within WinUI itself. This also reinforces our strategic commitment to WinUI as the native framework going forward. We know that performance is just one piece of the puzzle and that there are many other areas that deserve our continued attention. Rest assured, we remain focused on those as well.
Where We're Focused
We've been zeroing in on launch time, using File Explorer and Notepad as our primary benchmarks, with an emphasis on improvements that broadly benefit most apps.
The Results So Far
Here's what we're seeing for the WinUI portion of File Explorer launch:
When Can You Expect These Changes?
These improvements will be brought out of the development branch soon, and you will see them showing up in the
winui3/mainbranch. We'll also be bringing these changes into WinAppSDK 2.x where possible, though some changes may be too risky or complex to deliver as servicing updates.A Note on Breaking Changes
Some optimizations involve small or large breaking changes and will require apps to opt in. For example, we're optimizing default control styles, which should work fine for most apps but could cause issues for apps that:
SetterEach app can determine which of these changes to opt in to. Over time, perhaps as early as 3.0 or potentially in 4.0+, many of these will switch to opt-out, enabling the best possible performance by default.
Stay tuned for more updates, and thank you for being part of the WinUI community!
Beta Was this translation helpful? Give feedback.
All reactions