What is a High DPI Display?
In the past, most displays had (or the OS pretended to have) around 96 PPI, more or less.
If you differed a bit and had too small/large UI elements, you mostly just resized your default font size a bit and were kind of happy.
In the last years, more and more displays arise that have a much higher PPI values, which allows for e.g. very crisp rendering of text.
I arrived late in that era for my Linux machines by now starting to use two 163 PPI displays.
Just tweaking your fonts doesn’t help here, all other things will still be unbearable small, even if you in addition increase e.g. icon sizes.
A solution for this is the current trend to just “scale” your UI by some factor, for my displays some factor of 1.5 leads to the most pleasant sizes.
How does Qt handle that?
A detailed description on how Qt does try to tackle the challenges of such displays can be found here.
More or less the gist of this is: In your application you work on logical pixels (in most cases) and Qt will do the hard work for you to then paint that in real pixels with the right scaling applied.
In practice, this isn’t fully transparent to the programmer. For example, as soon as you work with QPixmap, you will think a bit about where which pixel variant is used. You need to be careful to not mix-up the size() of a QPixmap 1:1 with let’s say layout/widget sizes in such scaled scenarios, see here.
Fine, nice, but what does that mean in practice?
Let’s take a look at how this works out in practice using the latest stable release of KDE & Qt stuff:
- KDE Plasma 5.16.5
- KDE Applications 19.08.1
- KDE Frameworks 5.62.0
- Qt 5.13.1
My setup for the below experiments are two 163 PPI displays with scale factor 1.5.
I use some Manjaro Linux with open-source AMD drivers for some average middle class card.
The screenshots are taken on my second screen. I used PNG to avoid that some JPEG artifacts make the real rendering artifacts unclear, bear with the large size.
Experiments on Kate & Konsole
Let’s show the current state with Kate & Konsole, here how Kate 19.08.1 looks if you start it on the second screen with default configuration with COPYING.LIB of ktexteditor.git as file:
This looks kind of strange. What you see is actually no split screen, even that is a pure rendering artifacts, actually, the whole Kate windows is more or less one artifacts.
A user reported this in Bug 411965 - Rendering issue in dual screen hidpi setup. With my new setup I was able to reproduce that, on every Kate start :/
The user himself investigated this and came to the same conclusion as me, the culprit is some winId() call in KonsolePart. As Kate constructs the KonsolePart widget without a parent first and then insert it into a layout, the code inside the part will call winId() on a non-native widget.
This is now fixed and backported to the 19.08 branch.
This means, with 19.08.2, you will have the following experience:
This somehow looks more like an actual working application.
0 commenti:
Post a Comment