-
-
Notifications
You must be signed in to change notification settings - Fork 622
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
monitor resolutions unexpectedly change when entering into fullscreen with HiDPI GNOME (3 or newer) and a franction scale #2225
Comments
Thanks. Does a similar thing happen with a regular GLFW application? |
Sorry for the late reply. I've been digging a bit more, the summary would be:
The code that I've used to test this is available on this gist. I also recorded a video... really weird stuff going on: strange_things_spinoff.webmSince it's quite difficult to understand what's going on, here's the explanation:
(Note to self: maybe there's some way to mitigate the issue through software, for example using |
So, I've been digging even deeper. I don't know why I said that it's clear that this is not Ebitengine's fault; it may actually be, because GLFW actually behaves correctly, despite the weirdness and taking its time to properly set the screen at the right size. The summary is that GNOME and other desktop environments do some shenanigans to get fractional scaling working with xorg. Using Wayland works, but many apps have blurry text as they work on XWayland (compatibility mode for xorg), which is the main issue preventing wider Wayland adoption in my opinion. To summarize, when using integer scaling, the resolution of a 1920x1080 screen remains the same. When using fractional scaling, for example 125%, GNOME is not configuring the resolution as 2400x1350, but rather 3072x1728 (x1.6), and then indicates the apparently incorrect dpi of 200% to the application. If I manually override Now, there's a method behind all this madness, and somehow GLFW or GNOME (it's not xlib, because I actually wrote some code with xlib too in C to test the behavior there and xlib kinda only cares about whatever xrandr resolution is currently set) are making things work when I fullscreen on GLFW. So, the critical part is that period where even GLFW looks incorrect before readjusting (and this is what I don't know if it's done by GLFW itself or GNOME). What I suspect may happen is that once that readjusting happens, there's a callback invoked somewhere that leads Ebitengine to get confused again. So my question would be this: is there any callback on screen resize internally on Ebitengine that may explain these problems? The most telling sign to me has been that when I modify |
Hi, is this still an issue? |
Yes. I just set up a live usb and tested again, and it's still broken. The situation is basically that GLFW handles it properly and Ebitengine doesn't, because as you mentioned on #1307 (comment), no one knows if Linux needs scaling or not. The answer is that it depends on the desktop environment. Since GNOME supports fractional scaling by saying that the screen resolution is much bigger than it actually is and then downscaling internally, this is kinda weird and it breaks everything. In fact, I think the situation has become worse. First, after trying on v2.6.0 I hit this same crash #2794 (although for a different reason, maybe the "fake" resolution causing the mouse to go out of bounds or something). Then I updated to the commit that fixed this, and the scaling issue still exists. In fact, in windowed mode the window went crazier than I've ever seen it go. The resolutions from the pngs are accurate, from actual screenshots, so you can see how there's a 3072x1728 upscaling on windowed mode. For fullscreen, Ebitengine also believes that the resolution is 3072x1728, as that's what GNOME has configured and what xrandr probably reports, but then it's downscaled again to 1920x1024, leading to the complete disaster that you see in the second screenshot. Mouse coordinates also break badly. Honestly, while this should be fixable in Ebitengine, it's all the result of madness with fractional scaling in Linux in general. Maybe GLFW uses the actual monitor size while in fullscreen or has extra checks to self-correct when things go wrong, I don't know. It's hard to determine what would be the best way to go here. GNOME itself may change the behavior in the future, and other desktop environments may do the same and we simply aren't aware of it. It's a massive mess. |
CC @divVerent per 5bc7b93 |
Is the issue that only the bottom-left part is rendered? |
https://wiki.archlinux.org/title/HiDPI In order to reproduce this, do we need to setup GNOME's scaling factor to 2? (Cinnamon doesn't have such a setting) |
I think I could reproduce @tinne26's case with GNOME + 200% scaling + a fractional scaling: the rendering result is unexpectedly cut and only the bottom-left part is rendered. The temporal fix is always using GLFW's monitor size instead of XRandR size, but I am not sure when to use one and when to use the other. This is pretty confusing! When fullscreening in this situation, the monitor blacked out once, so the entire content scale might change. I'll try to fix #2343 first, and then revisit this later. |
I was testing a live usb with Ubuntu 22.04, which uses GNOME 42. After going to settings, display, enable fractional scaling and setting the scale to 125%, I noticed that game displays get too big and are shifted. I found this on Dr. Kobushi, but then also tested Bindless and found the same happening.
DeviceScaleFactor
is used. Unlike #1307, I was using a single screen (a laptop).Windows 11 seems to work properly instead under similar conditions.
The text was updated successfully, but these errors were encountered: