Graphics in Qt 6.0: QRhi, Qt Quick, Qt Quick 3D | Hacker News Reader

Graphics in Qt 6.0: QRhi, Qt Quick, Qt Quick 3D

qt.io

118 pointsTiredOfLife54 comments

One of the things that makes me seriously consider QT is Telegram. It is written in QT and in my opinion is one of the best examples of a cross-platform messaging app that Just Works(TM). Especially when one considers the horrible alternatives (looking at you, WhatsApp).

- Linux and Windows clients work smoothly OOTB. No UI lag/jitter. No RAM/CPU hogging.

- Drag and drop works. Floating video playback works. Background audio playback works. Minimize to tray, basic Markdown formatting, preview links, mp4 playback as gif, they all work flawlessly.

I don't even remember if I could throw something at it in a way that it would hang. I don't know how they did it, comprehensive unit-tests or good architecture design, but it sure is a breath of fresh air in this day and age which Electron monsters have set the bar too low that normal users don't remember the latency/resposive-ness of the 90s and 2000s software.

Any experienced QT devs can point us where to start learning QT? Good books/tutorials/blogs? I have some JavaFX experience...

Qt documentation and examples are the best place to start. Qt has some of the best documentation of any SDK I've seen (open or closed source). In a Qt install there are TONS of examples that you can just open in QtCreator and tinker with, all sorted by Qt module.

So much this. Their desktop UI is the (and I mean the only) reason I favor telegram over any other chat client I've ever seen. That includes all electron based UIs out there (signal, element, ...) but also older ones.

The only thing TDesktop struggles with is mixed DPI scaling.

And only because they implemented UI scaling before Qt did, and so don't rely on its mechanisms, which is now hard to refactor.

Can you explain more about the history of how Telegram implemented DPI scaling before Qt?

Looking at the source today, Telegram deliberately disables runtime DPI scaling after the application starts up. And maybe that's a good thing, considering how changing DPI between 100% and 150% leaves running Qt apps with misshapen text (sometimes tiny, sometimes huge and overflowing the menus and buttons).

I can't explain more about it than I got from stumbling over this:

https://github.com/telegramdesktop/tdesktop/issues/1121

And I only read enough of this to gauge whether there is a workaround. :P

I'm not a professional dev, but Qt is what I use for any personel project that needs a GUI. I don't think I had to use any resources outside of the official tutorials and documentation on the Qt site, it's well documented. My only complaint with the documentation is that for a lot of their example projects, it doesn't explain it step by step, it just shows you a bunch of code and it's up to you to look up what the different functions do. I was originally going to try to make web apps for my projects, but even with no prior C++ experience, working with Qt was easier to pick up than learning javascript and all the associated tooling required for web applications.

My experience with Qt is with the Python bindings via PyQt and PySide, but I was able to easily work from the C++ documentation which is outstanding. I developed a desktop app and just worked from one of the code examples as a starting point and built the app up from there.

The GUI designer seems pretty capable and I did try it out but I ended up coding everything directly. That's not a mark against QtDesigner, that's happened with every visual GUI design tool I've ever used.

Really? Even the macOS client is Qt? I was fully convinced that it was an AppKit app, it looks so good and is so responsive. That's extremely well done, IMHO.

For mac they have two desktop apps, one native and one in Qt.

Do you have an idea why they are doing that?

Why would you maintain 2 targets doing the same thing for an OS?

Maybe because the Qt one doesn't need any special Mac specific code. It's just another build target of the windows/Linux app

They've maintained Telegram and Telegram X for Android for a couple years now too, and for almost a year on iOS until X replaced it. This is far from a new thing for them: https://telegram.org/blog/telegram-x

There is a series on youtube by VoidRealms that walks you through using the basics of C++ Qt/QWidgets that I found helpful when I was learning Qt.

https://www.youtube.com/watch?v=6KtOzh0StTc&list=PL2D1942A46...

I was trying to learn Qt, and it just wasn't clicking, but watching these videos and suddenly Qt just made sense. This was nearly 10 years ago, and note that some of the syntax has changed, particularly Signals/Slots.

Maya, Houdini, and many other content creation tools are using Qt too. It's part of the https://VFXPlatform.com/ too.

But Qt is riddled with lots of tweaks, hacks, bugs - it's a beast, but sometimes a wild one, as you don't know what's going on deep down...

If you have commercial Qt license the support is pretty good. The source code is open source too, so you can go and look at what's going on if you need.

Tdesktop also supports Wayland, HiDPI and touch scrolling on Linux, btw, something lots of apps still struggle with.

However there are also many Qt apps that are terrible in this regard, which I find a bit sad because it suggests to me that Qt absolutely has the feature set to build great software, but doesn't really encourage it.

Yeah, or comparing IDE's : - Spyder (Qt, great) - Atom (Electron, mediocre) - Eclipse (Java, bad)

- VS Code (Electron, the best)

Rant ahead. I hate QtQuick controls with a passion. They don't generally feel better than Electron widgets. I say that as a linux user, which also happens to be a dev with tons of Qt experience, which understands the appeal of QML, but simply can't digest the user experience.

Most of the UIs designed with Quick (I'm thinking about some matrix clients I was playing with, but not exclusively) are also designed in a way which is totally orthogonal to what I would expect a desktop UI to be.

I've seen some of my favorite programs being ruined in the transition from QtWidgets to QML. One part being the horrid controls, the second being the "new way" of UI design QML easily adapts itself to.

I'm saddened by this. I was hoping Qt to be the escape path from the mess that Gtk was going to, but QML is worse.

Yes it’s unpleasant. Interestingly the Telegram desktop client kind of looks like a QtQuick app in its design and UX, but afaik is implemented only using Qt widgets, and it actually feels much nicer than equivalent real QtQuick apps such as the similar Matrix clients.

To me this is another example of great technology used badly. Most Qt Quick demos are abhorrently ugly (see this blog post) and the defaults for Qt Quick widgets are quite obnoxious. This makes many scroll areas especially feel incredibly wonky and unpleasant.

Qt Quick has historically been a toolkit for building custom look'n'feels, so essentially every Quick project needs a UI designer. For projects where custom LAF is important (e.g. all those car infotainment systems), this is not a problem and expected/accounted for. But for "general purpose" desktop apps - well...

Which is sad because Qt Widgets allows amazing native feeling apps and Qt Quick is supposed to be the future ...

What's the performance cost of using QTQuick? Does it require bundling a JavaScript interpreter with the application?

Starting with Qt 6.0, it should be possible to make QJSEngine/v4 (their custom JIT JavaScript engine) optional in your application:

>Make JavaScript an optional feature of QML.

>Having a full JavaScript engine when using QML can complicate things and is an overhead especially when targeting low-end hardware such as microcontrollers. It is however extremely useful in many use cases.

Source: https://www.qt.io/blog/2019/08/07/technical-vision-qt-6

is an overhead especially when targeting low-end hardware such as microcontrollers

What a sweet way of saying "yeah, it didn't work at all on microcontrollers"

what a diplomatic way of saying "yeah we would rather you didn't bloat your app for no good reason." ;)

You link against QtQuick to get the qml/js environment to run your qml apps. There is some performance overhead vs straight c++ code, but its negligible even on embedded systems.

I've been testing out beta and have noticed the Vulkan backend using around 30mb less memory than GL on Linux. Hopefully we'll see even more reductions when QML3 is released (which really focuses on embedded). Another interesting thing is that QML now has cross-platform desktop widget via QtQuickControls2 (i.e. native Windows and MacOS styles) and the improved CMake support is also pretty convenient. I can now get rid of my .qrc files and just write everything in CMake.

I really admire how smooth this migration was and it shows Qt really cares about minimizing breaking changes.

Tableau Desktop was written in QT and it has the best UX among similar tools. Just compare fast and sleek Tableau UI to clunky PowerBI interface and you will never want to switch to powerbi.

Can anyone recommend good learning resources to start developing desktop apps with QT?

https://qmlbook.github.io/ Is by far the best if you plan to use QML (strongly recommended).

Is Tableau written with QML, or QtGui? (I'm familiar with the latter, and have never used Qml)

Really a key question.

I just hope they bring back angle as a cross platform back-end so you can access "low level graphic hardware" without needing to implement also for Metal and Directx11.

It's what they describe though. You can use QRhi to write code that works on all platforms, it's low level enough already. ANGLE is redundant in this case and that's why it's gone. You don't need to write it for Metal or DX11, it'll map the RHI calls correctly and recompile SPIR-V to DXBC for example.

True, but if you are porting an OpenGl App (like Krita) you'll need to rewrite all your "hardware accelerated code" from scratch with maybe zero gain.

It appears that one might not even be able to make use of QRhi without porting all the QWidget-based UI over to Qt Quick.

Given how some high-profile Qt applications are using OpenGL, continuing with using ANGLE would seem to be the superior choice over having to rewrite everything with a completely new API.

I use QRhi for the shader pipeline in https://ossia.io which is a QWidget desktop app

Just curious: Is it possible to do rendering with QRhi inside QWidget in a similar way as one would do with QOpenGLWidget?

Actually, the post also stated that using `QQuickWidget` will force OpenGL composition, so if an application uses QML inside QWidget it looks like QRhi will not be usable at all. It would seem that QWidget composition does not support QRhi.

It works fine with QWidget::createWindowContainer on the QRhi viewport here : https://jeanmichael-gmail.tinytake.com/tt/NDc3MjgxOF8xNTA4MT...

top is your most classic QTreeView, bottom is the widget with content rendered through RHI (a preview of a shader effect)

Ah right, createWindowContainer should work for this.

I believe there is a reason why we don't call createWindowContainer with our use of QOpenGLWidget, though I currently can't remember it. If it still applies, then I suppose we might not be able to use QRhi.

Well... It's possible to use QRhi, but the blogpost explicitly says that QRhi is private and "QRhi or the new shader pipeline plays no role here at the moment, in Qt 6.0 at least. "

The combination of removing ANGLE (guaranteed baseline GL support on Windows) with it not being possible to use the new rendering stuff for APIs other than GL if you aren't using Qt Quick seems potentially problematic? (I have no experience with these tools though.)

Does anyone feel that this is too little too late?

Too little for what and too late for what? Qt has a massive install base in embedded and desktop, and plenty of weird niches like kiosk and interactive media. Also try building out some specialized UI featuring any kind of heavy computation and IO, there are very few practical choices for this. Qt is one of them

Most of it, not really. It sort-of makes sense as evolution, bigger issue IMHO is apparently nothing noteworthy about Qt 3D.

Hi, there's lots of things coming to Qt3D in Qt6, including an RHI backend, some new API changes, more performance improvement...

Main issue is that The Qt Company doesn't communicate about it at all. They made a commercial decision to go for a new API (qtquick3d) and as far as they are concerned, the graphics stack no longer includes qt3d.

We (KDAB) will put out a couple of blog posts about the upcoming changes soon.

A fair amount of work has went into porting Qt3D on top of RHI

Nice to hear it's not getting left behind, but funny how the post doesn't mention it when talking about Rhi then, but only the shiny new toys.

I don't know who would willingly pick Qt to do anything. It's a massive pain in the ass to use, the licensing is expensive and convoluted, and it codes like you're 20 years behind. The IDE is junk, the tooling is garbage, the slightest version shift breaks compatibility, the library conflicts with same names of objects, etc...

Qt is my new practical joke for engineers complaining about how bad they have it in their current stack.

Linux really needs a better UI framework because all other platforms are better and faster to implement in native languages/apis.

> It's a massive pain in the ass to use

I use it every day. No more pain than any other UI framework

> the licensing is expensive

Use LGPL if your platform allows it

> convoluted

Yes. The Qt company wants you to pay for their commercial license.

> and it codes like you're 20 years behind

With QWidgets yes. QML is the reason I would not want to start a new app in JS/Electron

> The IDE is junk

QtCreator is easily the best c++ in town.

> The slightest version shift breaks compatibility

Never had any problem the last 4 years with my projects upgrading from 5.8 -> 5.15 [1]

https://gitlab.com/kelteseth/ScreenPlay

> QtCreator is easily the best c++ in town.

Actually I would assert that belongs to C++ Builder, with its RAD tooling.

C++ Builder costs €1500 for the first year though and the community edition limits you to no more than €5k revenue, while Qt Creator is completely free and open source. So I don’t really see them in the same category, personally.

The point is what the tooling is capable of, price not being a factor.

Luckily there are places where employers still see a value paying for tooling.

Reply on news.ycombinator.com