[Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent
thiago.macieira at intel.com
Wed Jan 29 04:14:50 CET 2020
On Tuesday, 28 January 2020 06:48:53 PST Morten Sørvig wrote:
> There are several possible solutions:
> 1) The scale factor for screen positions is 1: [the current choice]
> Simple to implement. Device-independent virtual geometry may now have
> “gaps”, unoccupied by any actual screen. This may come as as surprise
> but is not completely unprecedented: you can create gaps also by
> arranging screens diagonally.
Indeed, there are some conditions that are impossible to implement if you
tried to scale differently when three or more monitors are present and not
arranged linearly. Like in the case:
If A is scaled and B isn't, then where does C start?
> 2) The scale factor for screen positions is the screen’s scale factor:
> Simple to implement, but unfortunately completely wrong, as was also
> concluded in qtbase/+/188493. This can cause overlapping screen geometry,
> if for example the position of an 2x screen is moved over an 1x screen
> closer to the origin.
> 3) Move the screen positions to create adjacent screens in
> device-independent space. Not-simple to implement: as pointed out on
> qtbase/+/188493 we need to implement heuristics which looks at screens
> closer to the origin. Can we make the heuristics accurate enough to support
> all possible screen configurations?
> 4) (Something else?)
> I've so far been in favor of keeping the simple-and-predictable (once you
> know what’s going on) 1) solution. However if there is a consensus for a
> different solution we could start looking into that. I don’t think this
> will be a patch release type change, though.
I don't know.
When I originally wrote 188493, the situation was horrible. All Qt
applications suffered from positioning problems on the second screen and dual-
screen applications (like the Plasma screen locker) would show a 1600 px
(scaled 2x) wide black area between the two screens. I kept the patch applied
and running just fine system-wide for a long time, until 5.13, and all
That has since been fixed. As I reported in the bug report, most applications
are working. KMail's main window and VirtualBox are so far the only ones I can
tell to have this problem. Spectacle also has a problem, but of a different
kind: its UI works, but the screenshotter on the second screen does not.
Another candidate is KRDC. Again, all of those worked fine under 5.12 with my
Even in 5.13 there were problems. When KMail is showing a progress bar on the
bottom right in the main window's notification area, if that window was on the
second screen, the progress bar would be painted again on the left.
I don't know what makes KMail different. I thought it was the use of a
qtwebengine window, but the qtwebengine examples seem to work fine.
My current theory is embedding of X11 content (QWidget::createWindowContainer,
use of QWindow::fromWinId, etc.). Which example should I try?
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development