Fullscreen across several monitors not working with screen scaling and AA_EnableHighDpiScaling
-
I have a windows that I need to show across all screens, under Windows I haves used this logic to achieve this:
setGeometry(QApplication::desktop()->geometry()); QWidget::show();Worked fine until I've enabled
AA_EnableHighDpiScalingfor the Application. Now it only works when screen scaling is set to 100% on all screens. With screen scaling set to 100% on my left monitor and 150% on my right I get a rect that doesn't cover all screens, something like this:

Is this a bug? Any known workaround to make a Window full screen across multiple monitors with screen scaling?
-
Hi,
Out of curiosity, does any of your other application support spanning on both screens with different scaling ?
-
@SGaist not sure about Qt Applications, don't use them that often on Windows but there are definitely some screenshots tools, like Windows Snipping Tool or Greenshot that support that behavior and work with my setup. My application is also a screenshot tool and as said, it used to work and still works without
AA_EnableHighDpiScalingbut disabling this settings breaks other stuff so I would like to keep it. -
It's something you should check on the bug report system.
The high DPI support is something that has been worked on but there might cases like yours that have not been encountered yet.
-
Just out of curiousity: You mentioned that you tried different scaling for the two screens. What happens when your monitors have different resolutions? I would expect similar behaviour. The best you can try is to do screenshots per screen and stitch them together.
-
Resolution is not a problem, the setup I have posted above is left Full HD and right WQHD. You would get the same if you stitch screens together, one smal rect and one large rect but you need a single rect so the difference is just filled with black but it's outside the visible view. With scaling the stitching is problematic because you can different scalings on different screens and that again has an impact on the position of screens.
-
I've been "lurking" (using the Watching feature of this thread). This struck me as an intriguing problem, even though I have no specific experience or personal concern with scaling at the moment.
Looking again (as I did just now) at the original screenshot you posted, it does feel like a bug.
It looks like the (computed?) screen rectangle you get from Qt in the buggy situation is really just off by some multiplier. The ratio of height to width seems "correct" (matching your actual screens).
My gut does feel that there could be a simple bug of some code path or paths where a simple multiplication needs to be done based on the presence/absence of
AA_EnableHighDpiScaling. Or maybe the Qt maintainers assumed that you (the Qt user) would need to add that multiplication somewhere in your own code? (I have no idea; this is all conjecture.)I would think posting this to the mailing list or the bugtracker would be well received (after searching both for prior discussion of this, of course).
You could also look through the commit history of https://github.com/qt/qtbase/blob/ba3b53cb501a77/src/gui/kernel/qhighdpiscaling.cpp to look for clues.
Hopefully some of the committers to that file would be present on the mailing list to help you. (Maybe start with the "interest" mailing list and ask if any readers know participants in the "develop" list who might like to be CC'ed)
-
@KH-219Design Qt is not really prepared for multiple monitors with different scalings. It is one thing to support scaling at all (i.e. a single monitor or all monitors with the same scaling). This is doable. However, it is a PITA to support monitors with different scaling. Problems vary depending on if your primary screen has higher or lower scaling than a secondary screen.
Initially, we hoped that changing from pixel sizes to relative font sizes would solve most of our problems. At least with the solution we chose (
QFontMetricsF(QFont()).height()) this is not sufficient. With this approach you will always get the font size on the primary screen; which means that your sizes will not adapt when moving your widgets to a different screen. EnterpixelRatio. This is a whole other beast. The worst part is that you cannot reliably (and portably) determine the pixel ratio of your widget in its constructor. Only after showing it you will be able to determine the pixel ratio of the screen it will be shown on. Furthermore, it means that your stylesheets (where we already changed everything frompxtoem) are screen dependent. Which means that you need to rescale all sizes according to the pixel ratio and update the stylesheet when moving widgets around. Also, you have to overwrite several events (move, resize, maximize, ...) to react to pixel ratio changes. Think you are done? Layouts don't work properly. Sometimes labels are too small to fit the entire text. The solution: derive all widget classes (e.g.QLabel) and overwritesizeHint()andminimumSizeHint()to consider the pixel ratio. For this we had other work arounds as this is not such a pressing issue (only very few places). And the solution messes with other cases as well.So, Qt does support monitor scaling. But, Qt does not support monitors with different scaling out of the box.
-
@SimonSchroeder I agree that the problems you describe regarding fonts and pixel ratios in a setting where widgets might move to another screen (or, I assume, straddle 2 screens) with different scaling.... those problems sound incredibly hairy indeed.
However, @dporobic (OP) does not seem particularly interested in those kinds of potential glitches at the moment. As I understand it, OP wants to be able to capture a "whole display buffer" (for screenshot purposes) that does not truncate and omit part of the (conjoined) display.
That seems like a much simpler problem to me than that of getting all the drawing and visual scaling to look natural in all cases.