Skip to content

Wayland: Fix logical and physical window size handling#119479

Open
buresu wants to merge 1 commit into
godotengine:masterfrom
buresu:fix-wayland-hidpi
Open

Wayland: Fix logical and physical window size handling#119479
buresu wants to merge 1 commit into
godotengine:masterfrom
buresu:fix-wayland-hidpi

Conversation

@buresu

@buresu buresu commented May 15, 2026

Copy link
Copy Markdown
Contributor

Details

Fixes several logical/physical window size conversion issues in Wayland HiDPI environments.

Godot internally uses physical window sizes, while Wayland protocols use logical sizes.
Several conversions between these coordinate spaces were missing or inconsistent, causing incorrect popup sizing and IME positioning under Wayland fractional scaling.

This PR also removes code that attempted to compensate for previously stored incorrect window sizes.
Existing saved window geometry values may still contain invalid data in project and might need to be reset manually.

This resolves a large portion of Wayland HiDPI popup and window sizing issues.
However, floating game window sizing during editor execution is still not fully fixed. Addressing this properly will require additional changes to the Wayland fractional scaling implementation and will be handled in a separate PR.

Tested on ArchLinux KDE Plasma 6.6.5 3840x2400 scale 250%

What problem(s) does this PR solve?

  • Fixes incorrect IME popup positioning under fractional scaling
  • Fixes inconsistent logical/physical window size handling on Wayland

@buresu buresu requested review from a team as code owners May 15, 2026 02:25
@bruvzg bruvzg self-requested a review May 15, 2026 04:51
@Chaosus Chaosus added this to the 4.8 milestone May 15, 2026

@deralmas deralmas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution!

I really appreciate the effort, but unfortunately I can't agree with most of the changes here. Converting the IME position sounds fine, but the rest of the logic brings some issues back.

Inheriting toplevel scale is somewhat fine, although there are really no guarantees that the window scale will actually be the same as the parent. Because of this, is there's any issue, I'd really like to see a deep-rooted solution. Popups seem to have stronger guarantees, as they're supposed to be extension to the toplevel itself. At least this is my understanding of it.

Removing "scale compensation" opens a few edge cases. Notably, changing the output scale while a window is open will lead to the same auto-restore issue. I could replicate it with this PR applied on top of commit 16bb065.

To replicate the bug you need to:

  1. Open a window (scale 1)
  2. Change scale (scale 2)
  3. Close the window (scale 2)
  4. Change scale (scale 1)
  5. Open the same window again (scale 1)

It will be restored to the wrong size.

What other issues have you been seeing? Are there issue reports open? Please note that there are also still a few engine limitations here and there, so not everything is fixable by simply working on the Wayland backend, although we can definitely improve it further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants