raylib
raylib copied to clipboard
[rcore] HiDPI not working as expected on Wayland protocol
Please, before submitting a new issue verify and check:
- [x] I tested it on latest raylib version from master branch
- [x] I checked there is no similar issue already reported
- [x] I checked the documentation on the wiki
- [x] My code has no errors or misuse of raylib
Issue description
Something happened in this branch merge https://github.com/raysan5/raylib/commit/190487383860c54d1746444f17b59c36decfca1e that broke the HiDPI behavior in Linux environment, if I switch to previous commit, before the merge, all is proper https://github.com/raysan5/raylib/commit/68b553cfc157a996e92da053d9e7b8beb92de0c0
Environment
- Operating System is Linux Ubuntu 22.04 running on Windows 11 WSL with
export LIBGL_ALWAYS_SOFTWARE=1
to avoid trouble with the Nvidia WSL drivers
Issue Screenshot
- Sample output on broken branch - it looks that something gets it to switch to wayland
INFO: Initializing raylib 5.1-dev
INFO: Platform backend: DESKTOP (GLFW)
INFO: Supported raylib modules:
INFO: > rcore:..... loaded (mandatory)
INFO: > rlgl:...... loaded (mandatory)
INFO: > rshapes:... loaded (optional)
INFO: > rtextures:. loaded (optional)
INFO: > rtext:..... loaded (optional)
INFO: > rmodels:... loaded (optional)
INFO: > raudio:.... loaded (optional)
INFO: DISPLAY: Device initialized successfully
INFO: > Display size: 3840 x 2160
INFO: > Screen size: 800 x 450
INFO: > Render size: 800 x 450
INFO: > Viewport offsets: 0, 0
WARNING: GLFW: Error: 65548 Description: Wayland: The platform does not provide the window position
WARNING: GLFW: Error: 65548 Description: Wayland: The platform does not provide the window position
WARNING: GLFW: Error: 65548 Description: Wayland: The platform does not support setting the window position
INFO: GLAD: OpenGL extensions loaded successfully
INFO: GL: Supported extensions count: 222
INFO: GL: OpenGL device information:
INFO: > Vendor: Mesa
INFO: > Renderer: llvmpipe (LLVM 15.0.7, 256 bits)
INFO: > Version: 4.5 (Core Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2
INFO: > GLSL: 4.50
INFO: GL: VAO extension detected, VAO functions loaded successfully
INFO: GL: NPOT textures extension detected, full NPOT textures supported
INFO: GL: DXT compressed textures supported
INFO: GL: ETC2/EAC compressed textures supported
INFO: GLFW platform: Wayland
INFO: PLATFORM: DESKTOP (GLFW): Initialized successfully
INFO: TEXTURE: [ID 1] Texture loaded successfully (1x1 | R8G8B8A8 | 1 mipmaps)
INFO: TEXTURE: [ID 1] Default texture loaded successfully
INFO: SHADER: [ID 1] Vertex shader compiled successfully
INFO: SHADER: [ID 2] Fragment shader compiled successfully
INFO: SHADER: [ID 3] Program shader loaded successfully
INFO: SHADER: [ID 3] Default shader loaded successfully
INFO: RLGL: Render batch vertex buffers loaded successfully in RAM (CPU)
INFO: RLGL: Render batch vertex buffers loaded successfully in VRAM (GPU)
INFO: RLGL: Default OpenGL state initialized successfully
INFO: TEXTURE: [ID 2] Texture loaded successfully (128x128 | GRAY_ALPHA | 1 mipmaps)
INFO: FONT: Default font loaded successfully (224 glyphs)
INFO: TIMER: Target time per frame: 16.667 milliseconds
This produces this image, when running the sample, which renders incorrectly, mouse events are also off
- Sample output on the commit just before the master merge
- This ones appears not to switch to wayland and all is still ok
INFO: Initializing raylib 5.1-dev
INFO: Platform backend: DESKTOP (GLFW)
INFO: Supported raylib modules:
INFO: > rcore:..... loaded (mandatory)
INFO: > rlgl:...... loaded (mandatory)
INFO: > rshapes:... loaded (optional)
INFO: > rtextures:. loaded (optional)
INFO: > rtext:..... loaded (optional)
INFO: > rmodels:... loaded (optional)
INFO: > raudio:.... loaded (optional)
INFO: DISPLAY: Device initialized successfully
INFO: > Display size: 1920 x 1080
INFO: > Screen size: 800 x 450
INFO: > Render size: 800 x 450
INFO: > Viewport offsets: 0, 0
INFO: GLAD: OpenGL extensions loaded successfully
INFO: GL: Supported extensions count: 222
INFO: GL: OpenGL device information:
INFO: > Vendor: Mesa
INFO: > Renderer: llvmpipe (LLVM 15.0.7, 256 bits)
INFO: > Version: 4.5 (Core Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2
INFO: > GLSL: 4.50
INFO: GL: VAO extension detected, VAO functions loaded successfully
INFO: GL: NPOT textures extension detected, full NPOT textures supported
INFO: GL: DXT compressed textures supported
INFO: GL: ETC2/EAC compressed textures supported
INFO: GLFW platform: X11
INFO: PLATFORM: DESKTOP (GLFW): Initialized successfully
INFO: TEXTURE: [ID 1] Texture loaded successfully (1x1 | R8G8B8A8 | 1 mipmaps)
INFO: TEXTURE: [ID 1] Default texture loaded successfully
INFO: SHADER: [ID 1] Vertex shader compiled successfully
INFO: SHADER: [ID 2] Fragment shader compiled successfully
INFO: SHADER: [ID 3] Program shader loaded successfully
INFO: SHADER: [ID 3] Default shader loaded successfully
INFO: RLGL: Render batch vertex buffers loaded successfully in RAM (CPU)
INFO: RLGL: Render batch vertex buffers loaded successfully in VRAM (GPU)
INFO: RLGL: Default OpenGL state initialized successfully
INFO: TEXTURE: [ID 2] Texture loaded successfully (128x128 | GRAY_ALPHA | 1 mipmaps)
INFO: FONT: Default font loaded successfully (224 glyphs)
INFO: TIMER: Target time per frame: 16.667 milliseconds
This produces this image, when running the sample, which render properly
Code Example
- Checkout and build the faulty version commit ID and run any of the default examples
This looks the same as the issue in raylib-go https://github.com/gen2brain/raylib-go/issues/354. With different compositors, it works but with Gnome/Mutter, it is like that (although I cannot reproduce it in VM with Gnome/Wayland). You can just use an X11 session, or compile with SDL, or try a different compositor, but it looks like it is specific to something in Gnome.
Just to add, before that commit, you were using X11 compatibility mode in Wayland, now you are using native Wayland mode. In raylib-go I added a build tag x11
(i.e. I just don't define -D_GLFW_WAYLAND) for users who want to keep the old/compatibility behavior.
I can't test because i don't have access to a Wayland based system, but could it comes from here ?
https://github.com/raysan5/raylib/blob/74680748b9abe05ceda5d412b61ff99addf72807/src/platforms/rcore_desktop_glfw.c#L1300-L1310
According to GLFW documentation, Wayland is sensitive to the GLFW_SCALE_FRAMEBUFFER
hint instead of to the GLFW_SCALE_TO_MONITOR
one.
Note that GLFW_SCALE_FRAMEBUFFER
is an alias of GLFW_COCOA_RETINA_FRAMEBUFFER
.
And the doc also suggest that GLFW_SCALE_FRAMEBUFFER
only affects Macos and Wayland,
while GLFW_SCALE_TO_MONITOR
only affect X11 and Windows.
So there should be no interferences if they are both enabled at the same time.
I tested with both hints enabled at once on my Linux X11, and found no difference.
So maybe, removing the optional #if defined(_APPLE_)
or adding a and defined(__WAYLAND__)
might ~solve~ improve the issue ?
if ((CORE.Window.flags & FLAG_WINDOW_HIGHDPI) > 0)
{
// Resize window content area based on the monitor content scale.
// NOTE: This hint only has an effect on platforms where screen coordinates and pixels always map 1:1 such as Windows and X11.
// On platforms like macOS the resolution of the framebuffer is changed independently of the window size.
glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE); // Scale content area based on the monitor content scale where window is placed on
glfwWindowHint(GLFW_SCALE_FRAMEBUFFER, GLFW_TRUE);
}
else glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_FALSE);
edit note that there is an other pending issue related to fullscreen and FLAG_WINDOW_HIGHDPI
Could you please test this PR #4151 ?