WinUI 3 Performance: A Leap Forward(github.com) |
WinUI 3 Performance: A Leap Forward(github.com) |
Older stuff is generally faster because it had to be built in a more resource poor time. Maybe the WinUI devs should be forced to work on systems with the Minimum System Requirements. Heck, maybe all Microsoft development should be done like that, so that some focus on performance is there from the start, instead of as an afterthought.
Both had huge issues UX wise, specially desktop, but performance and stability was never a issue.
Developers should always test their system on the minimum system requirement that they allow the system to be installed...
I remember I complained about WinUI performance years ago, and they told me at the time that "performance" was not the focus...
It is similar everywhere, they put out figures, like Teams rewritten from Electron to using native browser or something. claims to have 50% speed up. But 50% of what?
We used to have bundler on web and many vocals devs were suggesting 10 min was fast enough. Atom was fast enough, Electron was fast enough. Node.js was fast enough. It wasn't until things like Zed, ( or some other editor before that ), Bun and other Bundler showing them they were 10 - 50x slower before people realise.
WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
This is why all major new APIs since Vista are COM based.
So you get an UI framework with reference counting all over the place, and application identity, which is a kind of sandboxing, for the capabilities like in mobile OSes or macOS.
On the UWP subsystem, you get .NET Native and C++/CX, whose runtimes are WinRT aware and can elide those RC calls.
Whereas using WinRT on Win32, means regular .NET and C++, via interop frameworks CsWinRT and C++/WinRT, plain libraries.
So there is no elision, it is AddRef/Release all over the place.
Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
Not sure what you mean, I was using COM and C++ for Windows development in the late 90s.
> So there is no elision, it is AddRef/Release all over the place.
...and constructing an object is an insanely complex (and expensive) operation.
MinWin was the response to Longhorn. When most of the major goals of Longhorn failed to ship and those that did resulted in Vista, Microsoft did a reset. The MinWin project was a massive cleanup effort that promoted cleaner API boundaries and layer separation that defined a minimal bootable NT core at the bottom with reduced overall dependencies.
WinRT was introduced as an alternative API/runtime layer alongside Win32. Both WinRT and Win32 used COM concepts and ran ontop of the NT executive. WinRT was a modern async first object oriented natively sandboxed capability-based runtime that supported built-in projections over manual COM.
Microsoft tried to encourage everyone to adopt WinRT and the new sandboxed App Model on Windows 8, Windows RT, and Windows Phone. It used modern concepts and was more secure than the uncontrolled legacy surface area that Win32 exposed. They shipped those devices with Metro, a new "desktop" interface and didn't allow Win32 Apps. Unfortunately they shot themselves in the foot by shipping full Win32 based Office on Windows RT. This demonstrated that yes Win32 could run on ARM. After that, things fell apart and Microsoft decoupled many WinRT features from the WinRT/UWP model.
WinUI is an interesting UI framework that sits on top of this stack and is decoupled from it. This allows it to be updated independent of the operating system.
This might be off topic, but wish Apple would focused on Finder performance (app loading, window refresh, etc) like this blog post by Microsoft.
And in case you're curious, my disk is only using 250GB in use (50GB for Apps, 150GB for System Data, 50GB for macOS)
Also seeing stuff like text fields re-implemented from scratch in XML scares me. I don't like to see that.
The user experience of WinUI 3 isn't the worst
I think another way to get to the same effect is to say “A company needs good leaders”.
Did you not read the thread? That's literally stated as an explicit goal.
I also wish that they’d make WinUI work on macOS as well similar to Avalonia, but I think they probably won’t.
I spend a significant amount of time improving performance for our paying customers because performance absolutely matters to them. They might use a single simple feature hundreds of times during a normal workday. When we make that experience even 10% faster or smoother, they notice immediately and are genuinely delighted by it. That creates an enormous amount of goodwill.
And sometimes we can go even further and completely automate tedious workflows they hate doing manually. That’s even more valuable.
Developers with experience from the games industry understand this instinctively. Even when the software has nothing to do with games, they tend to have a deep appreciation for responsiveness, efficiency, and user experience. That’s why I’m always excited to hire people with that background.
When we worked on a SaaS HR platform, simplicity of use and the speed of getting an actual result from a workflow were some of the biggest contract renewal factors.
Even relatively small improvements strongly changed how customers perceived the product.
A lot of developers still underestimate how much “fast and simple” translates into trust, reliability, and user experience.
Is there any reason I would use this over something cross-platform like EGUI? I am kind of over software being OS-specific; this is one of the biggest compatibility mistakes we've made. Along with the related process of making drawing pixels on a display a complicated process!
With WinRT on top of Win32, the .NET Native runtime support now lives in CsWinRT, where they also only have C# into account, not even VB as it used to be on UWP side.
I still remain naively hopeful and cheer them on, however.
98: great. ME: bad. XP: great. Vista: bad. 7: great. 8: bad. 10: great. 11: bad
The only people that still buy into this are folks that never developed anything with WinUI, aka WinUI 3.0.
Since Windows 8, they messed up the development experience so bad, that they managed to turn many advocates like myself into vocal critics.
We avoid anything WinRT unless there is no way to do the same with Win32, classical COM (WinRT is an evolution of COM), or regular .NET (Forms/WPF).
And also post regularly about the actual state of the tooling unlike Microsoft's marketing posts.
Example, they keep mentioning about WinUI being supported in C++, but never mention how bad C++/WinRT dev experience has become, or that the framework is in maintenance, and has been superseded by WIL.
No one dog-fooded that thing.
I open Finder, click on Applications, search "Google Chrome". Top results? MarketingAnalytics.yaml, aria-proptypes.md, and so on, from some project I cloned off of Github into my home directory at some point. I guess the file contents include "Google Chrome"?
Clearly insane, but under the "Advanced" finder settings, it's easy to find "Search the Current Folder". Suddenly, you get the result you'd expect.
If I type "sa" the first result is Safari but if I type "safa" I get "Adguard for Safari.app".
In what world does this make sense?
It's a shame the system file managers feel so ignored, I would love to manage collections of files and folders rather than putting all my data into dedicated black holes with better viewing features such as Raindrop.io, Apple Photos, and Eagle 4.
I booted up an OLD imac stuck on 10.something, with an - I can't remember which gen - i5 and only 8gb of ram and I was blown away by how much it FLIES on that ancient hardware - even compared to my M1 Max Mac Studio
Apple Silicon is great. Everything else sucks.
And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.
This is not a rhetorical question. I do see some things, like antialiased drawing, etc (GDI is outdated, but I'm not convinced newer drawing could not be added.) But in general the classic ones work, including with accessibility, and are highly functional and batle-tested.
This is funny. You know, users also want games to be ridden of DRM but I don’t think the big companies cared about that for a long time. Users also want a lot of things that they never got, like a visible scroll bar sometimes.
And since Windows is primarily OEM or enterprise, I don’t know what users are going to do if Microsoft sticks to say Windows 7 UI? Like, uninstalling Windows and switching to Linux? Oh yeah, they are doing that right now.
Sure users want A or B, but that’s not important. What’s important is some idiot VP saw something and decided to push on, and other managers jumped in to grab the pie.
This is simply not true. You can built completely modern apps in WPF if you want. There is nothing about the framework that says your app is going to look 'old' except if you are just using default styles, and if that's the metric here then... we got bigger problems.
.. and get much less. Especially in accessibility. We've lost things like ubiquitous accelerator keys and even basics like "being able to tell where the edges of controls are or which is the active window".
The only real advantage WinUI has over WinForms is "responsive" resizing and display scaling.
Specifically?
> look and feel
Oh right so.
But it's been long gone that time where Windows had a minimum cohesive guideline.
At my day job, I choose Windows Forms with Blazor mixed in. That's old reliable Win32 tech + modern web tech, without any modern Windows tech mixed in.
I wish Microsoft just sticked to Win32 instead of reinventing the wheel with worse solutions.
> If you want a GUI that looks native, egui is not for you. If you want something that doesn't break when you upgrade it, egui isn't for you (yet).
With egui, it's an immediate mode GUI rather than retained mode and that has trade-offs: https://github.com/emilk/egui#why-immediate-mode. It's going to use more CPU (and battery power), there can be jitter and things shifting after the initial rendering, and other stuff. I think egui is very different from most cross-platform and platform-specific libraries.
With .NET MAUI, you're getting native controls, but you're now using a layer that's trying to use native controls on the underlying systems that don't always align completely. A lot of things act mostly the same across systems, but some things don't totally.
With Flutter, your app is going to be larger in part because you're shipping a rendering engine, runtime, widgets, etc. Does it have the look and feel you want? Maybe. That's a bit subjective. Does it handle all the little things correctly? When I'm using an app, I want it to scroll like how I'm used to scrolling working on my system. If you have differently styled buttons, I don't care, but if the scrolling feels wrong, it's going to annoy me. And there's so many little things.
Frankly, one of the reasons why Electron often does well is that a lot of the little things "feel right" because the UI is essentially a Chromium-rendered web page which users are used to interacting with. But that has downsides too - shipping a web browser with your app and the memory usage.
Heck, Qt apps in Gnome or GTK+ apps in KDE can look/feel "off".
And it'll all depend on your ecosystem. Often cross-platform solutions are lacking in accessibility - sometimes completely missing, sometimes half-baked and it works in some parts and not in others or just is janky. Memory usage is often higher. Many little things that make an app feel right might not be there. Many have slower startup times since they're loading a bunch of stuff that native apps don't need to. And it really depends on what approach the cross-platform library is taking to determine what is going to cause pain.
So you kinda have to pick your poison and what's acceptable to you will vary depending on your goals and tastes. Maybe React Native is the way to go for you with lots of native controls available and the feel that provides and the performance and size is acceptable.
If you create a Flutter or Kotlin Compose Multiplatform or AvaloniaUI app and put it on the web, it's not going to feel right as something like HN does. Right-click, text selection, etc. are all going to be different or missing. If you're creating a solitaire game, maybe that doesn't matter - you get desktop and web in one go and it's not a big deal.
But you have to know what you're building to know if the trade-offs being made are good ones. This isn't meant to sound anti-cross-platform, but as someone who has suffered some pain in this area, I guess I just wanted to impart that it isn't all sunshine and rainbows. Some times it can still be worth it, but just go in with your eyes open.
But it is used to implement various parts of Windows, such as the File Explorer, so any improvements are helpful for general system performance.
After Longhorn's failure, Windows team vouched to replicate all the .NET based ideas for Longhorn, as COM in Vista, followed by the Hilo code sample in Windows 7, how modern Windows applications should look like.
https://learn.microsoft.com/en-us/previous-versions/msdn10/f...
Best quote from Hilo, to show how Windows team sees .NET,
> So overall C++ is a good choice for writing Windows 7-based applications. It has the correct balance of the raw power and flexibility of C, and the sophisticated language features of C#. C++ as a compiled language produces executable code that is as close to the Windows API as is possible and, indeed, the C++ compiler optimizer will make the code as efficient as possible. The C++ compiler has many of options to allow the developer to choose the best optimization, and Microsoft’s C++ compiler is one the best ways to produce small, fast code. WinRT was the next step, coming back to the ideas that predated .NET as the COM evolution, before Microsoft got distracted with J++ and the project pivoted.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
https://web.archive.org/web/20190111203733/https://blogs.msd...
Missed the parts about the multiple reboots of the WinRT API surface between 8, 8.1 and 10.
The deprecation of .NET Native and C++/CX, replaced by tooling without feature parity to this day.
The set of Win32 APIs not available in UWP, even after the 8 and 8.1 (UAP) reboots.
WinUI 2.0 features not yet available on WinUI 3.0.
The pivot from Project Reunion, that six years later hasn't yet delivered on the goals from the BUILD 2020 announcement.
Microsoft is its worst enemy when it turns the hardest advocates in tale tellers from past wars.
Hope there's a day I can just use Dolphin on any system
Are these users in the room with us. If anything, today's UIs are dumbed down, mobile first abominations.
I recall it being pretty mediocre at release, just a reskinned 8.1. 10 started to come into its own much later after NT10
I'd love to know the exec who ordered Windows 11. It stinks of "I need a product on my resume that I launched because being Windows 10 "maintainer" sounds so pathetic on a resume."
It was like Delphi and C++ Builder kind of experience, then they killed the whole experience.
Rust with windows-rs is hardly any better, and coming from the same folks that killed C++/CX, with false promises at CppCon 2017, I don't have great hopes for it. They will jump ship again after a new shiny.
Well, until they killed the designer for WinUI 3.0, yet another flaw they don't talk about.
At least still around for Forms, WPF.
Huh? You absolutely can, the post you're replying to says as much.
defaults write com.apple.finder FXDefaultSearchScope SCcfMy graduation thesis was porting NeXT software to Windows 95, no need for heads up.
I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
Apple seems to have a much more powerful constraint system for this sort of thing, but I haven't taken the time to learn it yet, so I can't speak to whether I'd prefer it or not.
I'll never forget the Asus Netbook proudly boasting about its 1024MB of memory via a colorful sticker that'd be considered excessively large on a 17.3" workstation, somehow running Gimp with multiple layers on Windows 8 alongside a few Chrome tabs without a care in the world. UX of 8 and 8.1 was awful, but it was optimized and stable in ways that made me hopeful for what MSFT would deliver in the future. 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
The UX of Windows 8 was amazing on tablets, to the point where it's still my favourite touchscreen UI. The keyboard+mouse UX wasn't very good though, which is all that >99% of users ever used.
> 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
I had a similar experience with the earlier releases of Windows 10 also [0]. I'm not really sure when Windows's performance got worse, but it was definitely some time after that.
Contrary to Windows Phones, Android was still mostly JIT compiling, with Dalvik.
Windows Phone 8, used technology from Singularity, .NET Native apps were compiled on the cloud and what was downloaded was MDIL (Machine Dependent IL), on device only linking was performed.
Starting with Windows 10, everything was done on cloud and you got a binary targeted to device.
Android had to go through AOT compiler in version 5, 6, reintroduction of JIT with AOT on idle on 7, staring of PGO data across devices on 8, until it got into a similar kind of performance.
And to this day, NDK sucks compared with Windows Phone 8 C++/CX experience.
And WP 8.0 < didn't offer AOT for .NET apps. AoT only came as experimental on WP 8.1 with WinRT apps if I recall right. And on W10 and W10 Mobile, it comes as default for all UWP .NET apps.
Windows 8 had definitely MDIL support, with the Bartok linker from Singularity.
Thankfully the information hasn't yet fully disappeared from Internet.
https://stackoverflow.com/questions/11199234/compiling-windo...
https://www.zdnet.com/article/microsoft-details-its-strategy...
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
WP 8.0 didn't even had WinRT, only Silverlight apps, and all JIT. If you wanted native in 8.0, had to go with C++.
About Desktop, C++ was rarely used. Most apps were either .NET C# (JIT) or WinJS. JIT WinRT .NET was super slow, WinJS apps were even faster, which is why many apps were all WinJS, including inbox Windows apps, like the MSN apps.
Some people really have very selective reading capabilities.
"When you build your app in Visual Studio, the code is not compiled into a native image, but into a machine-independent Common Intermediate Language (CIL) binary file. (CIL was formerly known as Microsoft Intermediate Language, or MSIL.) This CIL file is what you submit to the Store when you’re ready to sell your app. At that time, the binary file is converted from CIL to optimized Machine Dependent Intermediate Language, or MDIL. Finally, when the user downloads your app to a device, the MDIL file is linked to produce a native image. These steps are repeated in your development environment whenever you deploy your app to a Windows Phone 8 device.
Pity that the Channel 9 videos on MDIL for Windows Phone 8 are no longer around.