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

121–130 of 143 posts

Re: WinUI 3 Performance: A Leap Forward

#121

Post by c-hendricks »

noahbp wrote: post #116
nitwit005 wrote: post #62

Earlier quoted context omitted.

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.

> nor, as far as I’m aware, can it be made the default

Huh? You absolutely can, the post you're replying to says as much.

    defaults write com.apple.finder FXDefaultSearchScope SCcf

Re: WinUI 3 Performance: A Leap Forward

#122

Post by electroly »

antiloper wrote: post #75
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…

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.

I'm not disagreeing, but I will point out that COM reference counting is an atomic integer operation. That's expensive. boost::local_shared_ptr exists because std::shared_ptr does sometimes cause performance problems. std::shared_ptr must be used sparingly. It's unlikely to matter in a UI scenario with long-lived objects because it, indeed, does use reference counting sparingly.

Re: WinUI 3 Performance: A Leap Forward

#123

Post by zeroc8 »

pjmlp wrote: post #53
LoganDark wrote: post #51

Earlier quoted context omitted.

WinRT isn't the most awful in the world to use from, say, Rust because there are auto-generated bindings, but I agree that C++ can be awful.

WinRT was great, back when using it via .NET Native and C++/CX. 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.

Speaking of Delphi - they should just buy Embarcadero and make Delphi and CppBuilder available for small money. That way they might get more and better apps for their platform again.

Re: WinUI 3 Performance: A Leap Forward

#124

Post by miguel-muniz »

tiffanyh wrote: post #30

I run macOS every day, and while I find Apple Silicon shockingly fast - I'm surprised at how shockingly slow Finder seems to be. 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)

I've turned into a bit of a data hoarder lately, I have a folder with over 43k images. Finder and File Explorer both struggle to even open the folder and load all the thumbnails, but XnView MP can load the folder without much issues.

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.

Re: WinUI 3 Performance: A Leap Forward

#125

Post by theICEBeardk »

pjmlp wrote: post #47
cosmic_cheese wrote: post #15

Nice to see. I wonder how feasible it would be to build a plain C interface… would be nice for building bindings to other languages.

If you enjoy calling COM vtables, and doing the reference counting by hand, by all means.

Yeah I remember doing that in one project. And then at least I found c++ and ATL back when it came out. I never went back to doing COM in C after that.

Re: WinUI 3 Performance: A Leap Forward

#126

Post by embedding-shape »

miguel-muniz wrote: post #124
tiffanyh wrote: post #30

I run macOS every day, and while I find Apple Silicon shockingly fast - I'm surprised at how shockingly slow Finder seems to be. 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)

I've turned into a bit of a data hoarder lately, I have a folder with over 43k images. Finder and File Explorer both struggle to even open the folder and load all the thumbnails, but XnView MP can load the folder without much issues. 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 view…

If you're keeping them in just one directory on a drive I think you might run into filesystem limitations because it's just too many files in one directory, you'll have the same issue on Windows and Linux too. You potentially need to look into directory sharding, splitting it up a bit :)

Re: WinUI 3 Performance: A Leap Forward

#127

Post by imtringued »

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…

20 years ago was 2006. Back in those days the vast majority of UI paradigms have already been explored for decades and the standard window pane UI has existed since the 80s. The biggest difference between back then and today is the eye candy and the fact that browser based UIs took over.

Re: WinUI 3 Performance: A Leap Forward

#128

Post by imtringued »

the__alchemist wrote: post #16

As someone who builds desktop apps: 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!

I agree. If the OS vendors want application developers to target their native UI framework, they have to put in that work to make it seamless. As of right now, every OS vendor has an incentive to make their UI toolkits incompatible with each other to ensure vendor lock-in.

Re: WinUI 3 Performance: A Leap Forward

#129

Post by jshier »

c-hendricks wrote: post #121
noahbp wrote: post #116

Earlier quoted context omitted.

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.

> nor, as far as I’m aware, can it be made the default Huh? You absolutely can, the post you're replying to says as much. defaults write com.apple.finder FXDefaultSearchScope SCcf

No need for a default, you can set that in Finder’s settings.

Re: WinUI 3 Performance: A Leap Forward

#130

Post by LoganDark »

pjmlp wrote: post #70
LoganDark wrote: post #59

Earlier quoted context omitted.

The thing is, at least compiled programming languages are statically typed. XAML is... well I don't think they even have a language server for it. My experience in Visual Studio (non-Code) was pretty bad.

Because the idea is to use the designer, not write it by hand. 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.

I think my favorite cross-platform GUI library is wxWidgets, because you can manually construct an interface from nested linear layouts, which is the way I prefer to construct my interfaces.

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.

Post reply on HN