[Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

[Thiago Macieira]

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:

  A   C
  B

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 
applications worked.

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 
patch.

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