Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS | Hacker News Reader

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

50 pointsdonboscow75 comments

There are many apps on Mac and Windows based on Qt, as well as ones built using the native SDKs exposed by respective platforms, like Cocoa and Dot Net. Are the ones built on Qt as smooth and performant as the native ones? Or will there be clear performance differences? There are questions like this on StackExchange, but they are more than a decade old, I am interested in knowing the current status!

On that note, how will an OS built around Qt perform compared to say iOS or Android, like Ubuntu Touch (assuming similar levels of underlying hardware)? Will Android and iOS and the apps on top of them will be naturally smoother, scrolls and app transitions being smoother than in Ubuntu Touch? Or is it that the Qt coding can be suitably tweaked in Ubuntu Touch to match iOS and Android performances?

View on HN

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.

When comparing on my machine, VSCode has much more latency than Qt apps for e.g. selecting text, reprocessing syntax coloration..

There are a few places where it's obvious VS Code isn't a native Mac app. For example drag & drop between apps doesn't work as it should.

(When initiating a drag, VS Code steals active app focus and brings its windows to front. It should stay in the background so that you can drag content into another app. This is a behaviour that views in Cocoa applications just inherit automatically.)

> (When initiating a drag, VS Code steals active app focus and brings its windows to front. It should stay in the background so that you can drag content into another app. This is a behaviour that views in Cocoa applications just inherit automatically.)

This is a good design. It's very dumb that on other OSes initiating dragging steals focus and often hides where you want to drop.

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.

Yeah but the claim was just that it was flatly obvious which apps were electron.

If the claim is just “it’s obvious which apps are electron if you have a decade old mid-range PC” then it’s not quite as bold of a statement.

That distinction of "flatly obvious" versus "obvious on a decade-only mid-range PC" seems to be pedantry. The parent comment doesn't say "flatly", for instance. In fact, it says "I find" which suggests personal experience, which would then mean that they weren't making a generalizable ("flatly obvious") claim.

Regardless, choosing the average consumer PC for your country (including the lower-class) is a much more reasonable benchmark than a high-end (your?) computer - and it seems more likely that tssge's machines (or mine) are representative of that average device than yours are.

I don't think that the statement was meant to be "bold" - it's pretty well-known that Electron performs extremely poorly on low-end devices, and the main reason why there's contention is because developers think that everyone has better computers than they actually do.

Well it’s not extremely obvious to me that VSCode is an electron app on my low-to-mid range laptop, but maybe I’m just an idiot.

Care to say specs of the lap?

Or maybe, more likely, the prevalence of electron apps lowered the average expectations?

Even on a very powerful modern machine you could probably tell the difference by looking at "abnormal" RAM usage.

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.

In my experience QML is buttery smooth on Linux, even on older hardware, but it just isn't as smooth on Windows.

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.

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?

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

It's a lot more complicated than that. I'm speaking from experience with Qt 5.14-15 and Qt 6.

Qt 5 defaults to "DPI scaling off", where text is enlarged but 1px is always 1px regardless of the current scale (so UI elements sized in px can end up too small on HiDPI displays). It has a mode with DPI scaling on, where 1px could be a fractional or integer number of on-screen pixels. Qt 6 only supports this latter mode.

Qt 5 defaults to rounding the magnification factor (output physical pixels / input program-facing virtual pixels) to an integer (except on KDE where it's passed through), while Qt 6 defaults to passing it through as a real number. (Qt 5.14+ and Qt 6 allow apps to customize what rounding method is used, except on KDE where it's passed through no matter what your app requests.) Passing through non-integer scale factors causes Qt's Windows-style theme (and some apps as well) to break spectacularly with rounding errors left and right, shifting as you move your mouse and focus between widgets. Breeze and Fusion handle this better (in my opinion using hacks rather than logical principled fixes), but I still prefer integer scale factors where I'm guaranteed that each x-by-y rectangle is the same integer number of on-screen pixels (which is useful for creating correctly sized off-screen buffers and blitting regions between graphical buffers).

All in all, if you drag a window between screens, Qt apps should handle it mostly fine. However, Qt doesn't properly respond when a display changes scale factor (like switching from laptop-only to external-only, or changing the scale factor of a monitor for testing), because Qt only checks for scale factor changes when the screen ID changes.

Unfortunately Qt makes it hard for apps to properly handle changing scale factors. If you cache the size of text in pixels, or "64 px * current scale factor", then the app changes scale factors, the app will resize, but your cached sizes won't change. I think property binding is a good solution to this (easier to use than Qt's private events, or handling QScreen-changed or QScreen-property-changed signals), but Qt isn't currently built around property binding. Maybe in a few years, Qt 6 will port the long tail of APIs to QProperty... I can only hope...

(Also Qt Creator's "new file" wizard somehow managed to have broken layout (too-small QLineEdit text fields) even when opening the app on a constant non-changing 125% scale. I suspect it's related to constructing a QFont without passing in a widget for context, causing it to use the global scaling instead of the current window's scaling. Or maybe it's because on Qt 5, Qt defaults to something like unscaled MS Shell Dlg 2 rather than scaled lfMessageFont.)

Well that's reassuring to hear that Qt6 is no better at this. Thankfully I'm not working on desktop apps anymore and I can stay on 5.15 LTS.

Are that many KDE apps using QML (as opposed to qwidgets), though? Or does parent remark apply to both?

Any idea why? I've heard Windows OpenGL drivers are less performant, especially AMD's, could that be part of the reason?

Qt 6 has moved away from OpenGL.

Now they do like game engines and use the native 3D APIs from each platform.

Which is to say DirectX on Windows and it is quite smooth.

Qt 6 is quite smooth.

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.

You should be able to use vcpkg on Linux too. It supports officially Windows, Mac and Linux.

What Linux distribution? Arch Linux has shipped Qt 6 for months, and Qt ships a web installer too (but it requires a Qt account and doesn't install the shared objects in a global location that apps can find).

I'm interested in Qt 6 for Ubuntu 16.04 which is currently what I build my AppImages on.

Is it bad that I thought of QT as a native UI framework?

If you mainly use Linux that would be a reasonable point of view to take.

However it runs in many environments so it is more like 'a cross platform framework'

It is native code, so in that sense it also native.

Qt is the native UI of many different operating systems

Just look at Telegram as a real example and compare that against the other messenger apps since the majority of them use Electron and Telegram uses Qt for some of its desktop clients.

You mean to say Telegram is smoother than other apps? Will try it out. In general, would you say that Qt is supposed to work just as buttery smooth and native on Mac or iPhone as a native app? And will an OS built on Qt like Ubuntu Touch will be as smooth and beautifully craftable as iOS apps on iPhone?

> You mean to say Telegram is smoother than other apps?

If those other apps are using Electron then yes; Telegram is smoother.

> In general, would you say that Qt is supposed to work just as buttery smooth and native on Mac or iPhone as a native app?

Yes. No difference in RAM, Disk, or CPU usage than any other native app.

> And will an OS built on Qt like Ubuntu Touch will be as smooth and beautifully craftable as iOS apps on iPhone?

Yes. One example is AsteriodOS which is an OS for smartwatches built using Qt. [0]

[0] https://asteroidos.org/

If you observe the Ubuntu Touch videos on YouTube, you will find that the animations, the graphics are not smooth and seamless, they stall, they freeze, they lag. Do you reckon it is more due to low end hardware underlying those phones as opposed to a fundamental problem?

Hard to say if it'll be as smooth as iPhone, but my experience with PinePhone shows that Qt-based environments (Ubuntu Touch, SailfishOS, even KDE) are way smoother than Phosh, which is based on Gtk. PinePhone isn't the most powerful phone out there, but I'd risk saying that SailfishOS is pretty smooth on it.

Telegram feels smoothish but not smooth.And it also feels out of place on Windows.

It's also not that performant compared to something like KakaoTalk (not sure what they use..perhaps they are truly native and only use OS libs)

Can you list beautiful Qt Apps that are open source

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 delay is hardly discernable and doesn't reduce its usability in any manner. QT is a mature framework and especially suited for C++ developers. It's one of the popular ways open source developers choose to make their software available on multiple platforms.

As for "OS built around QT" you can try it our yourself - KDE Plasma ( https://kde.org/ ) is a GUI for Linux / xBSD that is built with QT, and on the mobile scene, Sailfish OS ( https://sailfishos.org/ ) also chose QT for its OS UI and recommends it for app development on its platform.

All said, often nothing outperforms the native libraries in terms of usability. (Performance, in terms of resource use, is a different matter as there are GUI libraries that are actually lighter on the system than the native ones, and even QT).

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

Except that Qt might not be loaded/initialized by the time you launch your app.

I develop a Qt app which I benchmark regularly and the actual Qt initialization (from exec to an initialized QApplication) on an average computer is on the order of a few milliseconds (10-15 here).

Checked a bit more and the time to first frame, with GL set up, etc., is ~100ms.

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.

Not sure why you're downvoted. Even as someone who likes Qt, I definitely noticed that apps like XNView MP load slower than Win32/MFC apps (a few years ago on an older computer though).

> nothing outperforms the native libraries in terms of usability.

Win32 apps by default have hard-coded widget positions, which can't scale dynamically to larger fonts (though you can try DPI scaling, which is a choice between "blurry" and "text sometimes overflows the hard-coded widget sizes"). Though I don't like how sloppy Qt apps with multiple resizable widgets in a row have strange scaling breakpoints caused by various size policies and [minimum] size hints, and Qt apps tend to stutter when resizing.

What operating system are you referring to?

On Linux, Qt does have any underlying UI to emulate. On many others, my understanding is that this "emulation" is just theming. And on others it requires to draw on non optimized video buffers, which then become noticeable.

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.

If you are privacy-minded, KDE (with the kuserfeedback) should put you off, due to the user data it collects and sends back. You can disable the sending back, but not the collection.

There are a number of packets that depend on this, so you can't just remove it. Although you can recompile it to disable data collection, it's not something everyone just does.

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.

This is correct. KDE's user feedback collection is:

* Opt-in.

* Has several different levels of sharing and pretty clear about what is being shared.

* Even at the most relaxed level, it's fully anonymized.

The only criticism I've heard about it a long time ago was that even if you turn it off, it still will collect the data, locally on your machine. Which was a technical matter at the time and may have already changed.

KDE people are among the most privacy respecting bunch. Grandparent is spreading FUD (or has been misinformed as result of FUD). In a world that people are comfortable with Facebook and Google I find it funny that people would have privacy complaints about KDE.

Disclaimer: Used to be a minor kde contributor.

It's been in there for a least 2 years. A quick Google search leads me to no big rants about it. shrug

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.

Try 'KDE Neon' or OpenSUSE

KDE does have a long tail of (more or less maintained) apps, but there's nothing stopping you from installing the WM and plasmashell alone, along with a small selection of apps like Dolphin and Konsole. (You will spend a lot of disk space on KF5, and you might want to avoid Akonadi-based PIM apps too.) Do you think KWin/plasmashell is bad software (admittedly KWin has bugs, and plasmashell is worse off for being based off QML/JS and using janky drag-drop interfaces instead of traditional widgets), or are you avoiding it just because developers spend effort on apps?

You could try liquidshell as a plasmashell replacement, but I didn't like it (can't right-click to customize the panel, no Windows 7 style taskbar-dock IIRC).

There's Deepin too, but that's developed in China (which might be fine) and comes with a suite of applications (you probably won't like it either). I don't understand why you're fine with GNOME or XFCE though, since they also come with a suite of applications (GNOME has a file manager, text editor, terminal, IDE, browser, and VM GUI, and XFCE has a file manager, text editor, and terminal).

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.

What do you mean by rough? Not as smooth and responsive as say iPhone or iPad or Macbook?

I think it’s responsive enough, it just doesn’t do very much... e.g. app launcher is just a full-screen grid of icons in seemingly random order. At least being able to sort by name or something would be better.

Lumina is another option

I wouldn't go calling .NET a "native SDK" for Windows. That's like saying Java's a native SDK for Windows or macOS or Linux.

Why?

  > "That's like saying Java's a native SDK for Windows or macOS or Linux."

Not an unreasonable claim if you're packaging with Graal's native-image tbh.

Dotnet has NativeAOT, and JVM languages have GraalVM (with Kotlin Native too for Kotlin, and Scala Native too for Scala).

What you get when building an application with Dotnet Native, GraalVM native-image, Kotlin Native, Scala Native, etc, is architecture-dependent native code identical to compiling with "CC myfile.cpp"

So I don't find that unreasonable tbh.

If I can use NativeAOT/Dotnet Native Exports on .NET/GraalVM on the JVM to do this, as well as export a static/dynamic lib with a C ABI that I can use on whatever OS from C/C++/Rust code or whatever, I really don't know what else you need to call something "native" tbh.

Other than Python what are great Qt bindings available. I wish I could code for Qt in Zig or rust.

Guys, I see my question greyed out. And I also see some comments greyed out. What does that mean? They are getting downvoted?

most mac apps aren't based on QT, they are based on cocoa, mac people don't need to use 3rd party when the official solution destroy the competition

macOS apps are smoother than windows apps because microsoft forces JIT'd applications, which hurts both startup and UX, you can feel JIT doing work when there are animations / click on buttons, and installation is slow because it copies a shit ton of DLLs and a massive runtime

even more noticeable on 120hz+ monitors

linux is the worst, people are addicted to python, and god knows how slow it is

Most Linux and Windows apps do any significant computation except when relying on (usually) native/C/C++ libraries that do it (GUI, science stuff, IO ...). So it does not really matter if it is coded in Python, C# or C++, as most of the CPU time is spent on native code anyway.

Code quality is a way more important factor in app perceived slowness.

Obviously "smoothness" means something other than "differentiable everywhere", but I'm at a loss to know what.

Was my question not clear? If so, please tell me which part, I will be happy to clarify.

It was very clear.

It means minimal interaction latency, dropped animation frames, jerkiness etc. Pretty obvious.

Reply on news.ycombinator.com