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.
-
|
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. :) |
Beta Was this translation helpful? Give 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! |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure how valid this is: |
Beta Was this translation helpful? Give feedback.
-
|
https://community.devexpress.com/blogs/wpf/archive/2022/01/24/winui-3-performance-boost.aspx |
Beta Was this translation helpful? Give feedback.
-
Even your link's readme said it's outdated. dotMorten's recent benchmark tells the current story. WinUI is still slower than UWP (system XAML) as of today, yes, but slower than WPF...not really. Time to upgrade that xamlbenchmark using WASDK 2.0... |
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.
-
The Store app is largely using UWP, with WinUI3 to some extent |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
TIL. WinUI3 is definitely retarded. |
Beta Was this translation helpful? Give feedback.
-
|
It's a long standing issue with WinUI3. "How to remove the flickering of WinUI3 Window on resizing" |
Beta Was this translation helpful? Give feedback.
-
|
I don't see why it's surprising. Avalonia UI shares basically no code with WinUI |
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.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
ESRI is not a good fit for a display library. They are a commercial vendor and it would need to be licensed. As a long term spatial dev you also would not appreciate the stability aspect. If looking third party, look at leaflet. |
Beta Was this translation helpful? Give feedback.
-
Why would I ever look at a JS library when I am developing native? I have moderate experience with spatial dev, I still cringe at the thought of how many bugs in DotSpatial I had to squash, but Mapsui seems quite better. |
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.
-
|
They will never do this. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I could say, not just oneDrive, but also make File Explorer more cloud drives connectable |
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.
-
|
The (New) Outlook is a sheer proof that when it was conceived, in MS no one really cared about the quality of the final result. It is mindboggling how MS ever allowed such a unfinished, inferior, bad-performing app to ever craw out into the unsuspecting world. Not only that, but MS tried to shove it down our throats by installing it by default, retiring Mail & Calendar, and introducing a toggle button in classic Outlook. This means one thing - no one actually cared about quality. I do hope this changes. Speaking of classic Outlook, the new To Do pane is again a web app. Pathetic. |
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.
-
|
Just so you know, I'm working on idlgen 2.0 roxk/idlgen#102 (sorry for the shamless plug). I'm going to roll this out soon so stay tuned. |
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.
-
|
Also unless you miss the development experience of using Visual C++ 6.0 to develop ATL components, better not try to use C++/WinRT. |
Beta Was this translation helpful? Give feedback.
-
|
Do you want to deploy your app as a legacy exe (unpackaged)? |
Beta Was this translation helpful? Give feedback.
-
|
It is only for a single in-house machine, so legacy exe I believe. |
Beta Was this translation helpful? Give feedback.
-
|
@Listbd Just add
you can also right click on your project and click on Publish. |
Beta Was this translation helpful? Give feedback.
-
We are obligated to tell you MSIX is better I suppose, and if you don't want to deal with self-signed certs, you can create unsigned MSIX and use powershell to install it. Otherwise, as others have noted, your best bet is WASDK self-contained (if you don't want to run WASDK runtime installer) + unpackaged. |
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.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
Windows doesn't make it easy for us to develop Windows apps.
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". |
Beta Was this translation helpful? Give feedback.
-
|
I think Microsoft's critical error was with MFC: they should have pushed it more, used it extensively themselves, and made it more elegant. The Windows Qt, if you will. If they had banked on and poured their efforts into such, perhaps we would not have the fragmented picture of today, with framework after deprecated framework, along with endless performance issues. Apple, as usual getting things right, seems to be using the same class frameworks from the NeXTSTEP days. |
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 ruins the cross language approach, and much of the performance is related to xaml and xbf, how to write this in C++ and C#, if you want something like that try wice not necessarily good but it is a declarative C# ui |
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.
-
|
As you can see from the commits, the priority isn't high on that front, |
Beta Was this translation helpful? Give feedback.
-
|
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. |
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.
-
|
UWP has it, no need to go that far back. Another feature loss when going from UWP into WinRT on top of Win32. |
Beta Was this translation helpful? Give feedback.
-
|
Microsoft never had great visual editor. During the 90s, their approach was identical to the Cobol screen editors on the mainframe. Nothing innovative. |
Beta Was this translation helpful? Give feedback.
-
|
Microsoft UI design for developers is medieval times, I remember when I could design fully skinned apps in Delphi in 2000s visual editor, with the controls rendered real time in the editor, and now I have to code XML to design visual controls, this is 1000% regress. I would love flexible, live design editor with support for skinning, theming, hi-DPI testing at real-time, WITHOUT xaml code editing, just a nice visual designer with drag&drop, easy components connection by drag&drop, easy properties editing (I hate current properties window, its awful). I don't know who or when decied to stop improving visual editor for simple developers like me, who doesn't design the applications separately in Figma... Microsoft, can you hear me? |
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. Why?
|
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.
-
|
Even though WinUI3's performance has been getting better and better, it still can't hold a candle to the combo of XAML Islands and WinUI2 in UWP right now. |
Beta Was this translation helpful? Give feedback.
-
It'd be absolutely perfect if Qt could use XAML for UI development too. |
Beta Was this translation helpful? Give feedback.
-
|
@tusharsnx Only if you understand support as what used to be the ATL development experience with Visual C++ 6.0 in 2000's. It certainly doesn't have feature parity with C++/CX development experience, nor the experience roadmap shown at CppCon 2017. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps we can look forward to CsWinRT 3.0. This should bring a significant performance improvement. |
Beta Was this translation helpful? Give feedback.
-
|
One has to have been around since the early days of UWP to actually find out that CsWinRT 3.0 exists and what it might be about. I know the public development branch, the large majority of developers there don't even know that, zero communication on devblogs related to WinUI improvements, or the community calls. Also CsWinRT 3.0 won't fix the development experience for C++ developers, nor the current state of VS tooling for both communities. Instead we get blog posts about command line AI tools for project templates. |
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.
-
|
I have a bigger dream that all Microsoft Windows apps and OS components were native... starting from the awful New Outlook |
Beta Was this translation helpful? Give feedback.
-
|
The New Outlook must be publicly announced as a sad mistake, killed, buried and forgotten. |
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.
-
|
@ghost1372 I think the comment was redacted. It was above this comment when I last checked. |
Beta Was this translation helpful? Give feedback.
-
|
yes it is removed just less than 40 minute ago! |
Beta Was this translation helpful? Give feedback.
-
|
@ghost1372 what did the comment say? |
Beta Was this translation helpful? Give feedback.
-
|
Some details how they are fixing it with a gif demo showing a smooth resizing and a note that they are making it even better! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I think I saw that comment before, but it's gone now. |
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.
-
|
WinUI started in UWP, it was version 3 that was built on top of WinAppSDK, the rebranding of Project Reunion. Originally Project Reunion was about improving Interoperability between Win32 and UWP, and then they pivoted into porting just some UWP stuff into Win32. Here is the original announcement during BUILD 2020, |
Beta Was this translation helpful? Give feedback.
-
|
UWP was essentially designed specifically for Windows Phone; its CoreWindow and unique process model are tightly coupled, making it fundamentally different from Win32, WPF, and WinUI 3. Otherwise, they wouldn’t have spun off this component to create WinUI 3. I think it’s precisely because what you mentioned is nearly impossible to achieve that they abandoned UWP. |
Beta Was this translation helpful? Give feedback.
-
|
There is no such thing called "impossible" when you own the whole stack of technologies. Play with bits and bytes and you have what you need. How you want to play with those bits and bytes are your decisions; and MS played the wrong cards here unfortunately. They de-coupled whole .NET from their operating system. So the possibility is not the question here.
There you go. Now you have fully tested, feature proof UWP platform (name it as Non-Universal Windows Platform (NUWP) as you may like) that works for your own operating system (which is the only one your devs actually care when it comes to UI stack.), no leaks, with a xaml schema that is 20 years old and xaml compiler who got it's last update 10 years ago to bring x:Phase and x:Bind support.
Congratz, you have infinite power to create Windows applications. Anything else you do around these is definitely not a waste of effort, but you throw yourself as a company into a big hole and trying to make it to the top while you could've just not jump into the hole at all and climb more letters. WinRT and UWP architecture is the most capable architecture. It could've been the industry first-to-go in good hands. Ditching it for something "OS decoupled" was not good for your "OS" obviously. You ended up with people complaining how your OS is slow without caring how you created your "OS decoupled" UI framework. Same mistake 10 years ago with Windows Phone. Lack of good in-house apps for common tasks (back then) like Facebook, Instagram, Whatsapp etc. and you have people complaining how bad your OS because they can't like their parent's picture on Facebook or their Whatsapp app crashes because you did not properly spend time with partners to create first class apps for your own OS. This effort also supports for company's potential efforts on mobile. If ever exists, which when it comes to Microsoft I would say never say never. With AI shaping our world right now and all other devices getting more popular, what is your go to strategy for a potential Surface Phone or Surface Band? Anyways, it's getting out of topic, but I just wanted to share my thoughts on the decision making here. I see nice initiative after all the bad decision making years after years. Let this one solve most of the problems we are having (like previous ones fixed some...). |
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.
-
|
As if hardware acceleration were disabled, in contrast to smooth scrolling of the browser with low CPU usage. Don't know if the same thing is happening on 11 but would think so. Explorer.mp4 |
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.
-
|
Microsoft should port the timeless shell of 7, with 8's Task Manager and copy dialog, and work from there. Many would be happy with 7 on a modern kernel and infrastructure. |
Beta Was this translation helpful? Give feedback.
-
|
Remember the Hilo sample code for Windows 7? Now that was good. |
Beta Was this translation helpful? Give feedback.
-
|
I took a look now and the code is simple and elegant. |
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.
-
I meant hosting third-party Native AOT components in other native built apps. For instance, Native AOT components are unloadable, and having many of them in the same process can cause collision. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely, Microsoft's UI is a real mess. The current problems with WinUI3 are its poor performance, bulky program size, and hefty memory usage during runtime. If these issues get fixed, I'd be totally pumped to develop using native C++/WinRT. |
Beta Was this translation helpful? Give feedback.
-
Trying File Pilot today, I was impressed with the speed and size. Imagine if Windows targeted this level of performance.
In theory, the language-projection abstraction is light on the C++/WinRT path. Still, how does one explain the sluggishness pervading 11's shell, the context menus, the Task Manager, etc? Are managed-code components to blame? |
Beta Was this translation helpful? Give feedback.
-
Windows 11's shell is mostly fast for me (except FE). Context menu slowness is complicated. But rest assured it's not always* WinUI for UWP/WinUI's fault. There are plenty performant WinUI apps, e.g. nightingale, unigram. *Some controls are notoriously slow for some actions indeed, e.g. I'd also encourage all developers in the MS ecosystem to contribute, like developers in any other ecosystems that are being compared here (react, mobile native, etc). With the open source culture it's up to us to help the community grow. Disclaimer: I'm working on idlgen (shameless plug).
Managed code's problems are mostly startup time. As the new run dialog shows, even that can be circumvented (not using hack like photos did, of course). |
Beta Was this translation helpful? Give feedback.
-
Something has gone into 11's shell code causing this problem because 10 is still on the classic level of UI responsiveness, with allowances. I wanted to see what speed C++/WinRT was capable of, and found NanaZip, a fork of 7-Zip whose GUI seems to go through WinRT. Add to archive in Explorer's context menu and 7-Zip's classic Win32 window opens but the controls appear one by one. I wonder if Explorer's tabs taking long to appear isn't due to the same bottleneck.
People should contribute, and also hold Microsoft to account with constructive criticism. I think they should have stuck with MFC and developed it into the flagship Windows GUI framework, making it simpler and better. But it's too late now. |
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.
-
|
@brunossn I think this may be addressed by this repo, which seems to be a C# version of SwiftUI for WinUI apps |
Beta Was this translation helpful? Give feedback.
-
|
Perfect! I love it! |
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.
-
|
I upgraded to the Inserer Preview build, and the File Explorer is INSALENY FAST. |
Beta Was this translation helpful? Give feedback.
-
|
@aksoftware98 I am not sure what build you are talking about. Recent dev builds I believe just preload file explorer. Resize was broken for winui part and still broken. |
Beta Was this translation helpful? Give feedback.
-
|
@aksoftware98 you are using Low Latency Profile Feature which was recently published to insider and as a preview update to 25H2 users which i am currently using it! it just increase CPU usage for 1~3 sec! |
Beta Was this translation helpful? Give feedback.
-
|
@Tiktack, I know it's still broken for all apps, WinUI full updates are still WIP, but they are heading towards the right direction. |
Beta Was this translation helpful? Give feedback.
-
|
@aksoftware98 I agree, recent commits in winui3 branch are promising. But I just wanted to highlight that what you experienced most likely not connected to these commits. But I hope soon we get some perf bits in preview and it also would be really nice to get some blog post from MS with perf results that it brings to their apps. |
Beta Was this translation helpful? Give feedback.
and others
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