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

131–140 of 143 posts

Re: WinUI 3 Performance: A Leap Forward

#131

Post by pjmlp »

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.

The secret was .NET Native and C++/CX.

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.

Re: WinUI 3 Performance: A Leap Forward

#132

Post by pjmlp »

coffeeaddict1 wrote: post #112
pjmlp wrote: post #89

Earlier quoted context omitted.

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 is…

Which of those GUIs have you used where everything was a COM element?

Re: WinUI 3 Performance: A Leap Forward

#133

Post by pjmlp »

cptskippy wrote: post #120
pjmlp wrote: post #73

Earlier quoted context omitted.

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 l…

MinWin was a kernel refactoring mostly, still during Windows 7 days.

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.

Re: WinUI 3 Performance: A Leap Forward

#134

Post by tensor »

d3Xt3r wrote: post #46
tensor wrote: post #31

Earlier quoted context omitted.

Support for accessibility.

egui might not be great for it, but Slint and Iced have decent accessibility support (via AccessKit).

That must be new. Last I looked access kit wasn’t integrated into iced.

Re: WinUI 3 Performance: A Leap Forward

#135

Post by vitorgrs »

pjmlp wrote: post #131
adithyassekhar wrote: post #92

Earlier quoted context omitted.

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.

The secret was .NET Native and C++/CX. 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…

Windows 8 Inbox apps a lot of them where WinJS actually. But on Windows 8 even web tech was fine (speed-wise).

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.

Re: WinUI 3 Performance: A Leap Forward

#136

Post by Kadecgos »

drysart wrote: post #84
ChrisRR wrote: post #83

I'm stilll shocked that we're reinventining the wheel of things that were solved 20+ years ago, like UIs, and somehow making them massively more resource intensive

It's tempting to look at it that way; but that's being over-reductive. UIs of today are not the UIs of 20 years ago. Users expect much more from today's UIs, and UI toolkits necessarily get more complex as a result in order to deliver on those increased expectations. 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 i…

> it's going to look and feel like an application from 20+ years ago.

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.

Re: WinUI 3 Performance: A Leap Forward

#137

Post by pjmlp »

vitorgrs wrote: post #135
pjmlp wrote: post #131

Earlier quoted context omitted.

The secret was .NET Native and C++/CX. 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…

Windows 8 Inbox apps a lot of them where WinJS actually. But on Windows 8 even web tech was fine (speed-wise). 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.

I failed to mention WinJS, because hardly anyone used it, hence why it was dropped on UWP, with the WinRT API surface reboot on Windows 10.

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

Re: WinUI 3 Performance: A Leap Forward

#138

Post by vitorgrs »

pjmlp wrote: post #137
vitorgrs wrote: post #135

Earlier quoted context omitted.

Windows 8 Inbox apps a lot of them where WinJS actually. But on Windows 8 even web tech was fine (speed-wise). 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.

I failed to mention WinJS, because hardly anyone used it, hence why it was dropped on UWP, with the WinRT API surface reboot on Windows 10. 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...

.NET Native was experimental in WP 8.1 and W8. On 10, it becomes mandatory and you couldn't even publish a JIT .NET app to Store.

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.

Re: WinUI 3 Performance: A Leap Forward

#139

Post by pjmlp »

nxobject wrote: post #82
antiloper wrote: post #75

Earlier quoted context omitted.

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.

Yes, and it doesn't do COM style reference counting to the level like WinUI does, so the point being?

My graduation thesis was porting NeXT software to Windows 95, no need for heads up.

Re: WinUI 3 Performance: A Leap Forward

#140

Post by pjmlp »

vitorgrs wrote: post #138
pjmlp wrote: post #137

Earlier quoted context omitted.

I failed to mention WinJS, because hardly anyone used it, hence why it was dropped on UWP, with the WinRT API surface reboot on Windows 10. 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...

.NET Native was experimental in WP 8.1 and W8. On 10, it becomes mandatory and you couldn't even publish a JIT .NET app to Store. 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 W…

I AM NOT TALKING ABOUT .NET NATIVE!

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.

Post reply on HN