Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WinUI 3 Performance: A Leap Forward

github.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: WinUI 3 Performance: A Leap Forward

#111

Post by GoblinSlayer »

adithyassekhar wrote: post #92
vitorgrs wrote: post #63

Earlier quoted context omitted.

If I recall right, Windows 8 and Windows Phone 7/8 during the 2010's were all developed on low end devices. 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 tha…

I am sure this was posted so many times before but someone should reverse engineer the windows 8 era windows phones. Those were ridiculously smooth compared to android and ios with just 512mb of ram.

I think android apps bundle pretty heavy batteries, so it's like Electron, but in java, windows can make it faster by just pushing the GUI into the system as it always did.

Re: WinUI 3 Performance: A Leap Forward

#112

Post by coffeeaddict1 »

pjmlp wrote: post #89
antiloper wrote: post #81

Earlier quoted context omitted.

Can I see the profiler data that shows AddRef/Release being a performance bottleneck?

Yes, learn to use one and point it to a C++ Github project full of shared pointers.

While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.

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).

Re: WinUI 3 Performance: A Leap Forward

#113

Post by kelvinjps10 »

Levitating wrote: post #14
kelvinjps10 wrote: post #11

Earlier quoted context omitted.

10 was bad 11 is a little better but no enough. With win10 they started with more annoying ads and the start menu with apps and the click bait news in the start menu

still leaps better than windows 8

Idk, I literally skipped Windows 8.

Re: WinUI 3 Performance: A Leap Forward

#114

Post by orphea »

LoganDark wrote: post #27

The user experience of WinUI 3 isn't the worst I've seen but the developer experience is absolutely awful. I tried to make a simple app with it and the number of hacks I needed to get it to look and feel the way I almost wanted was horrible. And the documentation sucks. I had to read the system level implementations of controls in order to figure most of it out. It's great those implementations are available to read,…

  The user experience of WinUI 3 isn't the worst
WinUI apps are unbearably laggy when you resize them.

Re: WinUI 3 Performance: A Leap Forward

#115

Post by noahbp »

adithyassekhar wrote: post #106
gucci-on-fleek wrote: post #104

Earlier quoted context omitted.

> UX of 8 and 8.1 was awful 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 believ…

It’s after the 2019 release, they started optimising for ssds.

I’d argue they started doing that a bit earlier. My hard drive from 2011 made using Windows a miserable experience any time the search indexing or windows defender scans kicked on, no later than 2016-2017.

Re: WinUI 3 Performance: A Leap Forward

#116

Post by noahbp »

nitwit005 wrote: post #62
rudedogg wrote: post #38

Earlier quoted context omitted.

The “Apps” app is so bad on macOS too (seems built off of Spotlight?). I’ll type the exact app name and it’ll suggest the one on my phone, an installer in Downloads, etc.. No one dog-fooded that thing.

Someone has realized the search results are insane, as there's at least one obvious fix buried in settings: 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 sett…

It’s incredible that “Search the Current Folder” is not the default, nor, as far as I’m aware, can it be made the default.

Re: WinUI 3 Performance: A Leap Forward

#117

Post by vrighter »

Rohansi wrote: post #8
dgellow wrote: post #7

Earlier quoted context omitted.

Anyone who tried to do serious native windows dev has been burnt so often by Microsoft. I really wanted to give them the benefit of the doubt with WinUI 3 but I really cannot anymore. Until proven otherwise I expect absolutely nothing to improve meaningfully. It’s extremely sad for those of us who were dumb enough to think Microsoft take on modern GUI would be interesting to follow closely, we are in 2026 and WPF is…

> we are in 2026 and WPF is still the way to go IMHO. Why not Avalonia? It's not Microsoft but it is a spiritual successor to WPF, cross-platform, and open source.

That's the one I use now. But it still feels laggy to me.

Re: WinUI 3 Performance: A Leap Forward

#118

Post by ksec »

kristianp wrote: post #58

> 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!!!. 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 do…

>WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!.

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.

Re: WinUI 3 Performance: A Leap Forward

#119

Post by sunaookami »

Citizen_Lame wrote: post #110
sunaookami wrote: post #103

Earlier quoted context omitted.

Well most people just press the Windows key and type to open a program which works exactly the same on Win8. And personally I loved the start screen. And how often do you really need the start menu?

That's the most brain dead take I've seen in a while. Yes, forget about start menu and lets just search everything or use giant pictorials designed for 'blind' people.

Not what I said.

Re: WinUI 3 Performance: A Leap Forward

#120

Post by cptskippy »

pjmlp wrote: post #73
kristianp wrote: post #58

> 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!!!. 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 do…

It is quite easy to know why. 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…

Eh... not exactly.

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.

Post reply on HN