[rcore] HiDPI not working as expected on Wayland protocol

iongion commented 5 months ago

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

gen2brain commented 5 months ago

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.

gen2brain commented 5 months ago

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.

SuperUserNameMan commented 2 months ago

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

SuperUserNameMan commented 2 months ago

Could you please test this PR #4151 ?

raysan5 / raylib