Qt 5.14 Is Bringing Significantly Better HiDPI Support

[zanny]

No. "Normal desktop widgets" are QWidget widgets and KDE themes are QWidget themes.

Just FYI, over half of the system settings modules in KDE are now written in QML and about a third are using Kirigami. You can't tell from just using them which tech its implemented in.

[cynical]

Dang.
I wish QWidgets could get some sort of GPU assistance... GTK3 already does so to some extent, and GTK4 will almost fully use the GPU for GUI rendering.

He is mistaken. Kirigami (the mobile controls which are convergent) is a limited set of widgets, but QtQuick has all the stuff you need, and it does adapt to the system theme. In fact, you are likely using many applications made in it without realizing. KDE Discover is one example off the top of my head.

[cynical]

I hope it will be helpful for the remaining fractional scaling issues of Plasma (thinking mostly of the terrible line artifacts).

That horizonal line issue is literally the sole reason I write off KDE. Wayland fixes it, but then wayland has its own problems in KDE...

[ssokolow]

He is mistaken. Kirigami (the mobile controls which are convergent) is a limited set of widgets, but QtQuick has all the stuff you need, and it does adapt to the system theme. In fact, you are likely using many applications made in it without realizing. KDE Discover is one example off the top of my head.

That's Qt Quick 1. From what I remember, Qt Quick 1 adapts to the system theme, but Qt Quick 2 is the one that's fully GPU accelerated and is receiving the development attention.

I also wasn't able to find a clear answer on whether Qt Quick 1 is still actively supported or considered deprecated.

[Baguy]

That horizonal line issue is literally the sole reason I write off KDE. Wayland fixes it, but then Wayland has its own problems in KDE...

Going forward their will be alot of attention on plasma's Wayland. I expect in a year or so it will be a very good experience.

[cynical]

That's Qt Quick 1. From what I remember, Qt Quick 1 adapts to the system theme, but Qt Quick 2 is the one that's fully GPU accelerated and is receiving the development attention.

I also wasn't able to find a clear answer on whether Qt Quick 1 is still actively supported or considered deprecated.

Oh you're right I see. QtQuick2 does all the fancy new stuff.

Qt Quick Controls 2 is shipped with three styles: Default, Material, and Universal. The latter two are based on Google's Material and Microsoft's Universal styles, which are platform- and device-agnostic designs with publicly available specifications. They fit well to the notion, "one template, one behavior, multiple design languages / styles", that Qt Quick Controls 2 builds upon. There are no native styles in Qt Quick Controls 2 - all styles are cross-platform and look the same on all platforms.

Ugh, they look awful and utilitarian. I agree, that's not usable unless a breeze theme is made for it.

[Elv13]

That horizonal line issue is literally the sole reason I write off KDE. Wayland fixes it, but then wayland has its own problems in KDE...

You are mistaken too, but I admit this is confusing. QtQuick1 widgets are drawn on the CPU (individually) then placed using the GPU (compositing). This didn't work very well and was the worst of both world. Qt Quick 2 does it the other way around. Everything is GPU based, the *themes* can still be based on QStyles. When you do that way, it is the equivalent of background images in CSS used by most websites. More work is done by the GPU. When you are using GPU capable themes, then no pixmaps are created. When you are using QStyle like KDE QtQuickDesktopStyle, then it generates a bunch of corner pixmaps and other assets then upload them.

The advantage of doing it the QtQuick2 way is that you pay for what you use. QPainter/QStyle/Cairo/GTK+Pango+Cairo are CPU bound even if the drawing backend is OpenGl/Vulkan. The API is still function calls and that will *always* be sequential on the CPU. If you use sequentail API with GPU backends, then there is extra synchronization involved and it ends up slower than pure CPU+single upload. Only game engine style toolkits like CSS, QtQuick and GTK4 scene graphs are using the CPU to create an update pipeline to the GPU rather than using CPU bound APIs to imperatively draw everything. These system are better at animations and, when not abused, are more power efficient than CPU drawing for DPI larger than 150. The reason is that the number of pixels grows at the square of the DPI. The GPU never cares because it has to draw all the pixels anyway, so from that point of view it isn't an overhead.

[patstew]

Oh you're right I see. QtQuick2 does all the fancy new stuff.



Ugh, they look awful and utilitarian. I agree, that's not usable unless a breeze theme is made for it.

Good news, it has been there for 2 years in KDE https://jriddell.org/2017/09/06/qqc2...-beta-release/
Qt also ships with the desktopish Fusion style as well nowadays, in addition to the ones it was released with. https://doc.qt.io/qt-5/qtquickcontrols2-styles.html#

[cynical]

You are mistaken too, but I admit this is confusing. QtQuick1 widgets are drawn on the CPU (individually) then placed using the GPU (compositing). This didn't work very well and was the worst of both world. Qt Quick 2 does it the other way around. Everything is GPU based, the *themes* can still be based on QStyles. When you do that way, it is the equivalent of background images in CSS used by most websites. More work is done by the GPU. When you are using GPU capable themes, then no pixmaps are created. When you are using QStyle like KDE QtQuickDesktopStyle, then it generates a bunch of corner pixmaps and other assets then upload them.

I think you misquoted me, since I was talking about KDE and Wayland there, but yes, I haven't looked at Qt Quick development in a while, and didn't know about the changes in version 2. The point about you are making about sequential API calls is funny, it reminds me of why DMA was invented.

[Elv13]

I think you misquoted me, since I was talking about KDE and Wayland there, but yes, I haven't looked at Qt Quick development in a while, and didn't know about the changes in version 2. The point about you are making about sequential API calls is funny, it reminds me of why DMA was invented.

DMA buffers cannot work on GPU accelerated toolkits. There is never a pixmap buffer (beside in the screen itself). All components are either composited vector paths and/or mimaps. Also, the problem with "damage detection" of pixbufs in DMA buffers is one of the big reason these toolkits were rewritten for GPUs. The main problem, again, is that the pixel count grows squares along the DPI. At 96DPI, all those GPU accelerated toolkits are slower than old DMA/pixbuf based ones. At 500 hundred, however...