[rcore] HiDPI not working as expected on Wayland protocol

[iongion]

Please, before submitting a new issue verify and check:

• I tested it on latest raylib version from master branch
• I checked there is no similar issue already reported
• I checked the documentation on the wiki
• My code has no errors or misuse of raylib

Issue description

Something happened in this branch merge 1904873 that broke the HiDPI behavior in Linux environment, if I switch to previous commit, before the merge, all is proper 68b553c

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

2. 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]

This looks the same as the issue in raylib-go gen2brain/raylib-go#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]

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]

I can't test because i don't have access to a Wayland based system, but could it comes from here ?

raylib/src/platforms/rcore_desktop_glfw.c

Lines 1300 to 1310 in 7468074

	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
	#if defined(__APPLE__)
	glfwWindowHint(GLFW_COCOA_RETINA_FRAMEBUFFER, GLFW_TRUE);
	#endif
	}
	else glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_FALSE);

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]

Could you please test this PR #4151 ?