Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.1k
Qt: Fix HiDPI handling on X11/Windows#30399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
With X11, there is only ever a single scale, regardless of monitors asin Wayland, so it's always the highest scale (i.e., it's 2 if you have1.5&1-scaled monitors). Thus we get no change events and don't updatethe internal scale. On Wayland though, as noted in the other issue fromQt devs, you only get the fractional scale after the first expose, sothere'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 thatinitial call, and because Wayland always has at least one event atstartup, 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 usingfractional scaling, will change with a subsequent event to the correctone. This does cause a few extra changes on startup, but should be moreconsistent across platforms.
QuLogic commentedAug 6, 2025
In fact, if on Wayland you had ainteger scale, then the previous code would also be incorrectly scaled, since then you don't get that first event that happens with fractional scales. |
QuLogic commentedAug 6, 2025
Note, I do expect this to fix the problem on Windows as well, but I cannot test it. |
MAKOMO commentedAug 8, 2025
MAKOMO commentedAug 8, 2025
QuLogic commentedAug 8, 2025
It's possibly also a problem on macOS; we just haven't had any reports of such, and I can't test it myself. |
anntzer commentedAug 11, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I can confirm that the issue also exists on macOS, bisects to#30345, and is fixed by this PR. I'll approve on that basis (and because the fix makes sense, of course). |
77a16b9 intomatplotlib:mainUh oh!
There was an error while loading.Please reload this page.
…399-on-v3.10.xBackport PR#30399 on branch v3.10.x (Qt: Fix HiDPI handling on X11/Windows)


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 thatalso 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