Qt: Fix HiDPI handling on X11/Windows #30399
Open
+24
−38
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With X11, there is only ever a single scale, regardless of monitors as in Wayland, so it's always the highest scale (i.e., it's 2 if you have 1.5&1-scaled monitors). Thus we get no change events and don't update the internal scale. On Wayland though, as noted in the other issue from Qt devs, you only get the fractional scale after the first expose, so there's always at least one event there. In the older/pre-#30345 code path, in `showEvent`, we'd call `_update_screen` to set callbacks for its changes, and that _also_ called `_update_pixel_ratio`. In the new code, we don't have that initial call, and because Wayland always has at least one event at startup, it all seemed to work. So just add the `_update_pixel_ratio` call in the new code path as well. On X11, this will be the highest integer scale needed and never changes. On Wayland, this will also be the rounded-up integer scale, but if using fractional scaling, will change with a subsequent event to the correct one. This does cause a few extra changes on startup, but should be more consistent across platforms.
In fact, if on Wayland you had a integer scale, then the previous code would also be incorrectly scaled, since then you don't get that first event that happens with fractional scales. |
|
Note, I do expect this to fix the problem on Windows as well, but I cannot test it. |
|
Is this a X11/Windows issue only? I observe a degration on macOS as well. Window in the background is MPL 3.10.5, the one in the foreground is 3.10.3, both running on Qt/PyQt 6.9.1. 
|
|
On the positive side: adding that 
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR summary
With X11, there is only ever a single scale, regardless of monitors as in Wayland, so it's always the highest scale (i.e., it's 2 if you have 1.5&1-scaled monitors). Thus we get no change events and don't update the internal scale. On Wayland though, as noted in the other issue from Qt devs, you only get the fractional scale after the first expose, so there's always at least one event there.
In the older/pre-#30345 code path, in
showEvent, we'd call_update_screento set callbacks for its changes, and that also called_update_pixel_ratio. In the new code, we don't have that initial call, and because Wayland always has at least one event at startup, it all seemed to work.So just add the
_update_pixel_ratiocall in the new code path as well. On X11, this will be the highest integer scale needed and never changes. On Wayland, this will also be the rounded-up integer scale, but if using fractional scaling, will change with a subsequent event to the correct one. This does cause a few extra changes on startup, but should be more consistent across platforms.Fixes #30386
PR checklist