Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wayland: Auto UI scale is rounded up when using fractional scaling #89257

Open
Tracked by #88346
ghost opened this issue Mar 7, 2024 · 4 comments
Open
Tracked by #88346

Wayland: Auto UI scale is rounded up when using fractional scaling #89257

ghost opened this issue Mar 7, 2024 · 4 comments

Comments

@ghost
Copy link

ghost commented Mar 7, 2024

Tested versions

v4.3.dev4.official.df78c0636

System information

Fedora 39, Radeon 780M, GNOME Wayland

Issue description

Godot does not follow the system display scale, which can result in it being way too big or way too small on some screens.

Display Scaling setting in Godot seems to only be able to automatically set itself to integer scales and it seems to be global, as in, it does not adjust the scale according to different displays in multi-monitor setups.

Steps to reproduce

  1. Run Godot with --display-driver wayland in a Wayland session
  2. Depending on your display and scaling configuration, Godot's UI may or may not be too small or too big.

Minimal reproduction project (MRP)

N/A

@ghost ghost mentioned this issue Mar 7, 2024
@Riteo
Copy link
Contributor

Riteo commented Mar 7, 2024

Fractional scale is actually implemented (you'd otherwise see at least some blur), what's missing is a good way to detect Godot's UI scale.

It's a bit complicated to explain: on Godot, the UI scale can not be changed at runtime, so it just queries the screen scale at startup, which on Wayland is always an integer (as the fractional scale is a window extension).

In practical terms, these are the solutions that come to mind, in order of "correctness":

  • The proper one is being implemented in [WIP] Implement native DPI scaling. #86022: native runtime scaling, per window querying and so on.
  • A more hack-ish but still relatively proper solution would be to add just a method to query the window's screen, as the fractional scale is per-window and not per output as the auto-scale logic assumes.
  • We could also hack the screen scale logic to return the main window size, which already got proposed before.

One of those solutions will be implemented by the release, I just haven't got around to do that yet. I'd push for the second if the first doesn't get resolved in time.

In the meantime, a work-around is to set the editor's scale manually (interface/editor/editor_scale).

Also, note that multi-display fractional scale is effectively broken AFAIK until runtime UI scale changing (the first fix) is implemented. This is consistent with every other platform unfortunately.

Don't hesitate to ask further info, HTH :D

@Riteo Riteo modified the milestones: 4.3, 4.x Mar 7, 2024
@Riteo Riteo changed the title Fractional scaling does not work on Wayland Wayland: Auto UI scale is rounded up when using fractional scaling Mar 7, 2024
@Riteo
Copy link
Contributor

Riteo commented Mar 7, 2024

Heads up, I've renamed the issue to be more clear, please tell me if that's not what you're experiencing.

@Riteo
Copy link
Contributor

Riteo commented Mar 16, 2024

All right, I have implemented a partial solution: #89574. If you have a single screen, or if the one the editor is run on, it will select that scale. Otherwise, it will fallback to the biggest size it can probe (which will be still rounded up).

Note that fractional multi-head is impossible (the UI will "resize" between screens instead of staying nice and consistent) without the deep and complex changes done by #86022, as that's an actual engine-wide limitation.

Edit: to be clear, this is the third solution, as it's the least invasive kind. The fact that there's already a SCREEN_OF_MAIN_WINDOW magic index makes things good enough IMO.

@ghost
Copy link
Author

ghost commented Mar 16, 2024

Thanks! Tested it, this works OK for now as a workaround.

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

No branches or pull requests

3 participants