> 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 done like that, so that some focus on performance is there from the start, instead of as an afterthought.
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 that "performance" was not the focus...
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.
WP was incredibly smooth and they were willing to reinvent UX from first principles in ways that'll to this day make me reach for Sailfish OS if I didn't need physical buttons, but I must bring up the desktop version of Windows from that day.
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.
> 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 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.
[0]: https://news.ycombinator.com/item?id=45743066
It’s after the 2019 release, they started optimising for ssds.
I never used 8 because I hate the UI. But I used 7 for a long time. I recall that 7 was blazingly fast on a 2GB notebook back in the early 2010x. But then that was already way beyond its minimum system requirement.
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 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.
I don't believe it.
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.
For that matter, AppKit was first released on a NeXT with a 25 MHz 68030 and 8MB of RAM.
Of course they cause problems as well, you not believing it doesn't change profiler facts.
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.
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).
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
embarrassing
> WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
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.
Of course you were it predates all the way back to OLE in Windows 3.x, but not the extent it is pervasive in modern Windows past Vista.
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...