Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
ksunden merged 2 commits intomatplotlib:mainfromQuLogic:fix-qt-x-hidpi
Aug 14, 2025

Conversation

@QuLogic
Copy link
Member

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, inshowEvent, we'd call_update_screen to 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_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.

Fixes#30386

PR checklist

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
Copy link
MemberAuthor

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

@QuLogicQuLogic added this to thev3.10.6 milestoneAug 6, 2025
@QuLogic
Copy link
MemberAuthor

Note, I do expect this to fix the problem on Windows as well, but I cannot test it.

@MAKOMO
Copy link
Contributor

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.

Screenshot 2025-08-08 at 14 34 33

@MAKOMO
Copy link
Contributor

On the positive side: adding thatself._update_pixel_ratio() inshowEvent() seems to fix the issue on macOS as well.

Screenshot 2025-08-08 at 14 41 57

@QuLogic
Copy link
MemberAuthor

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
Copy link
Contributor

anntzer commentedAug 11, 2025
edited
Loading

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

@ksundenksunden merged commit77a16b9 intomatplotlib:mainAug 14, 2025
40 checks passed
meeseeksmachine pushed a commit to meeseeksmachine/matplotlib that referenced this pull requestAug 14, 2025
@QuLogicQuLogic deleted the fix-qt-x-hidpi branchAugust 14, 2025 18:59
tacaswell added a commit that referenced this pull requestAug 15, 2025
…399-on-v3.10.xBackport PR#30399 on branch v3.10.x (Qt: Fix HiDPI handling on X11/Windows)
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@anntzeranntzeranntzer approved these changes

Assignees

No one assigned

Labels

Projects

None yet

Milestone

v3.10.6

Development

Successfully merging this pull request may close these issues.

BUG: Qt hi-dpi regression on windows and X11 with mpl 3.10.5

4 participants

@QuLogic@MAKOMO@anntzer@ksunden

[8]ページ先頭

©2009-2025 Movatter.jp