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

[Morten Sørvig]

> On 27 Jan 2020, at 20:16, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> I had fixed this prior to 5.13 but the patch was never accepted:
> https://codereview.qt-project.org/c/qt/qtbase/+/188493
> https://bugreports.qt.io/browse/QTBUG-58329
> https://build.opensuse.org/package/view_file/
> home:thiagomacieira:branches:openSUSE:Factory/libqt5-qtbase/0001-HighDpi-Fix-
> handling-of-the-screen-origin-point.patch?expand=1
> 
> The problem is that Qt is adding device-independent pixels to device-dependent 
> ones when calculating the positions of anything outside the first screen and 
> coming up with nonsense. This can be seen from these lines in qtdiag:
> 
>  Geometry: 1920x1080+3200+0 (native: 3840x2160+3200+0) Available: 
> 1920x1080+3200+0
>  Virtual geometry: 5120x1080+0+0 Available: 5120x1080+0+0

This is by design: the scale factor for screen positions is always 1. So we’re
arguably not mixing coordinate systems here. Is it a design bug? 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.

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.


> 
> The number 5120 is 1920+3200, but 1920 is a scaled number and 3200 isn't. That 
> means 5120 is a nonsensical result. The end result is that positioning of many 
> things are off.
> 
> I've filed https://bugreports.qt.io/browse/QTBUG-81695, but I'm reporting here 
> because this issue affects kmail majorly in 5.14 and thus makes it VERY 
> difficult for me to work. Please consider this bug a P0.

Something is clearly wrong with the menu positioning for kmail there. We should get
to the bottom of that, with P1 priority (not sure about P0 :)

I suggest we continue discussing the menu position bug on QTBUG-81695.

Cheers,
Morten



> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> <qtdiag.txt>_______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development