Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS
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?
76 comments
[ 0.52 ms ] story [ 240 ms ] threadMy application has a setting where you can choose whatever arbitrary scale you want, smaller or larger than default.
Virtualbox's windows GUI is Qt and shows the problem pretty easily.
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.)
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.
I may need to set up some other way to use it for my builds…
I do see Qt 6 in MSYS2 though, so maybe I can use it only for my Windows builds.
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/
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)
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.
* 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.
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.
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).
I will give it some more time to develop though. I love the direction they are going in.
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).
In the end it does not matter that you push pixels from qt5gui.dll or shell32.dll, no ?
Checked a bit more and the time to first frame, with GL set up, etc., is ~100ms.
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.
> 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.
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.
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.
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.
(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.
"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.
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.
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.
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.
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
Code quality is a way more important factor in app perceived slowness.
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.