Live data from Hacker News

Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

news.ycombinator.com

41–50 of 77 posts

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#41

Speaking of QT...I've wanted to switch to a QT-based DE for a while but I don't like lxqt or Plasma. It would be really cool if there was another option.

What's wrong with KDE plasma? The beauty (and curse) of Plasma, is that it's so configurable, you can make it look and feel like anything else.

Admittedly haven't tried KDE in a few years but I don't like their apps and although I think the UI has come along quite well when I tried it last I thought it was very ugly at first boot.

I have never needed a KDE app since I've used Linux. So the idea of running a DE that has developed a million apps I don't need instead of putting that dev time in the DE itself has always been a put-off for me.

Crucify me for this if you want, but I just want a GNOME clone built in QT. Or a XFCE clone built in QT that isn't ugly as sin like LXQT.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#42

My personal experience in using QT apps is that they load / render perceptibly slower than the native UIs and QT applications are slightly bulkier in size (storage space and memory). This is kind of understandable as QT emulates the UI through its own library (unlike, say, Lazarus IDE / Delphi GUI library that directly use the native UI library). However, size doesn't matter much today, and the very minor rendering d…

> This is kind of understandable as QT emulates the UI through its own library (unlike, say, Lazarus IDE / Delphi GUI library that directly use the native UI library). In the end it does not matter that you push pixels from qt5gui.dll or shell32.dll, no ?

Specifically, with regard to what we are discussing, it does as QT, technically, does a poorer job than the native libraries of the OS in "pushing" these pixels to the screen.

In general too, when it comes to user interfaces - a lot of work has already been done to make an interface that is familiar and easy to use for the user. Often the recreation miss some design goals or usability features or even edge cases, and that ultimately provides a poor user experience. (For example, some native UIs allow a screen reader for blind users to read out the the UI elements - if your UI library doesn't support it, blind users won't be able to use applications built with such a library).

QT does a great job for multi-platform application development. But like all other multi-platform toolkits, it does have its downsides.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#43
post #23
post #20

I find Qt is on par with native apps. Didn't even know it wasn't considered native. Electron apps on the other hand are very obvious from their resource usage, general laggyness and slow startup time. Say compare Discord (Electron) to Telegram (Qt) and it's like night and day.

Eh, I don't think it's always obvious - for instance Visual Studio Code I would never have guessed was an Electron app.

It might not be obvious if you have a high-powered dev computer. It's very obvious if you have decade-old mid-range hardware (like me) or five-year-old low-end hardware (like millions of users).

"I don't know what you're talking about, Electron is fast on my machine." makes about as much sense as "The application runs on my machine." Other people do not use your machine.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#44

Speaking of QT...I've wanted to switch to a QT-based DE for a while but I don't like lxqt or Plasma. It would be really cool if there was another option.

Try cutefish! It’s somewhat rudimentary still, but looks great, stays out of the way, works great for me

Cutefish is very rough. I do like the look and feel, but I didn't like having what felt like a tablet OS on my desktop.

I will give it some more time to develop though. I love the direction they are going in.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#45
post #20

I find Qt is on par with native apps. Didn't even know it wasn't considered native. Electron apps on the other hand are very obvious from their resource usage, general laggyness and slow startup time. Say compare Discord (Electron) to Telegram (Qt) and it's like night and day.

Qt is native, if you talk about running compiled and linked code that directly accesses native resources (C++ will work directly with the Apple OS).

It is its own application framework (windows, buttons, labels, etc.), but, from what I can see, it does a damn good job of using native system resources, where possible.

The answer to the OP is "it depends." There's no "Philosopher's Stone" for cross-platform development. I'd say a significant number of applications could benefit from Qt. A smaller number, from other hybrid systems. A lot of good development tools are Qt-based, and I like them fine.

I have no experience with mobile Qt, though. Might be a different kettle of fish.

I write native Apple, using Swift, and native frameworks, like AppKit, UIKit, and WatchKit. I have not yet started working extensively with SwiftUI, but I like what I see (except the documentation).

I feel that true native development will always deliver the best UX, but, for many applications, the difference may not be worth the extra cost.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#46

Earlier quoted context omitted.

Yep, that's why KDE is so smooth even on older hardware. But on Windows, some QT apps (GnuPG pinentry-qt for example) often have weird scaling issues where they de-snap and move out of their place.

Qt still hasn't figured out to work with Windows desktop scaling. It's a nightmare on high-DPI displays. I wrestled with this 5 years ago and it's still not fixed.

[deleted]

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#47
post #19

Earlier quoted context omitted.

With QML you can implement native fractional scaling but I don't know how it interacts with Windows's scaling mostly because I don't have a high DPI screen on my Windows computer. My application has a setting where you can choose whatever arbitrary scale you want, smaller or larger than default.

Here's a fun test when you get a High-DPI screen for testing: hook two screens to Windows, one high and one low-DPI. Then drag the Qt app from one window to the other. Virtualbox's windows GUI is Qt and shows the problem pretty easily.

Is this your only complaint with regards to Qt being a "nightmare" to use on a high DPI display?

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#48
post #40

Earlier quoted context omitted.

This is the first time I'm hearing about this. Do you have a source?

i had the api reference open as i was trying to automate something in kwin... https://api.kde.org/frameworks/kuserfeedback/html/index.html https://community.kde.org/Policies/Telemetry_Policy

Which indicates it's opt-in so off by default. Also there's a pretty clear (IMHO) configuration in the settings that states what is send based on the level you select. So what's the problem? It's only a way to contribute usage feedback if and only as much as you want to.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#49

Earlier quoted context omitted.

Here's a fun test when you get a High-DPI screen for testing: hook two screens to Windows, one high and one low-DPI. Then drag the Qt app from one window to the other. Virtualbox's windows GUI is Qt and shows the problem pretty easily.

Is this your only complaint with regards to Qt being a "nightmare" to use on a high DPI display?

Not at all. That's just the one that's most obvious to users.

Re: Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

#50
post #30

Earlier quoted context omitted.

I'm patiently waiting for it to become available in open-source repositories. I may need to set up some other way to use it for my builds…

QT 6.1.3 is available via vcpkg already.

Things are not so peachy over in Linux.

I do see Qt 6 in MSYS2 though, so maybe I can use it only for my Windows builds.

Post reply on HN