raylib icon indicating copy to clipboard operation
raylib copied to clipboard

[rcore] HiDPI not working as expected on Wayland protocol

Open iongion opened this issue 11 months ago • 4 comments

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

  1. 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

image

  1. 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

image

Code Example

  • Checkout and build the faulty version commit ID and run any of the default examples

iongion avatar Mar 17 '24 12:03 iongion

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 avatar Mar 17 '24 14:03 gen2brain

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.

gen2brain avatar Mar 17 '24 14:03 gen2brain

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 avatar Jul 10 '24 11:07 SuperUserNameMan

Could you please test this PR #4151 ?

SuperUserNameMan avatar Jul 10 '24 15:07 SuperUserNameMan