HiDPI scaling and glfw 3.4

[arntanguy]

Hi,

First of all, thanks for all the work on magnum and related projects, hugely useful!

I am in the process of packaging magnum in nixpkgs. Getting it to build and run, including the plugins was not an issue. However I'm running into issues regarding HiDPI scaling in glfw 3.4.0. Considering #243 this seems to be quite a sticky point (no surpises there ^^).

If I link the TriangleExample, against glfw 3.4.0, with Plateform::GlfwApplication, I get a very low resolution window, scaled up multiple times bigger than expected:

Whereas running the same code against the Plateform::Sdl2Application, I get the expected behaviour:

Tested with

add_executable(TriangleExample TriangleExample.cpp)
target_link_libraries(TriangleExample PRIVATE 
          Magnum::Sdl2Application
          # Magnum::GlfwApplication
          Magnum::GL
          Magnum::Magnum
          Magnum::Primitives
          Magnum::Shaders
        )

#include <Magnum/GL/Buffer.h>
#include <Magnum/GL/DefaultFramebuffer.h>
#include <Magnum/GL/Mesh.h>
#include <Magnum/Math/Color.h>
#include <Magnum/Platform/GlfwApplication.h> // or #include <Magnum/Platform/Sdl2Application.h>
#include <Magnum/Shaders/VertexColorGL.h>
#include <iostream>

namespace Magnum { namespace Examples {

class TriangleExample: public Platform::Application {
    public:
        explicit TriangleExample(const Arguments& arguments);

    private:
        void drawEvent() override;

        void viewportEvent(ViewportEvent & event) override
        {
        GL::defaultFramebuffer.setViewport({{}, event.framebufferSize()});
        std::cout << "windowSize: " << event.windowSize().x() << "x" << event.windowSize().y()
                  << ", framebufferSize: " << event.framebufferSize().x() << "x" << event.framebufferSize().y()
                  << ", dpiScaling: " << event.dpiScaling().x() << "x" << event.dpiScaling().y() << std::endl;

        }

        GL::Mesh _mesh;
        Shaders::VertexColorGL2D _shader;
};

TriangleExample::TriangleExample(const Arguments& arguments):
    Platform::Application{arguments, Configuration{}
        .setTitle("Magnum Triangle Example")
        .addWindowFlags(Configuration::WindowFlag::Resizable)
    }
{
    using namespace Math::Literals;

    struct TriangleVertex {
        Vector2 position;
        Color3 color;
    };
    const TriangleVertex vertices[]{
        {{-0.5f, -0.5f}, 0xff0000_rgbf},    /* Left vertex, red color */
        {{ 0.5f, -0.5f}, 0x00ff00_rgbf},    /* Right vertex, green color */
        {{ 0.0f,  0.5f}, 0x0000ff_rgbf}     /* Top vertex, blue color */
    };

    _mesh.setCount(Containers::arraySize(vertices))
         .addVertexBuffer(GL::Buffer{vertices}, 0,
            Shaders::VertexColorGL2D::Position{},
            Shaders::VertexColorGL2D::Color3{});
}

void TriangleExample::drawEvent() {
    GL::defaultFramebuffer.clear(GL::FramebufferClear::Color);

    _shader.draw(_mesh);

    swapBuffers();
}

}}

MAGNUM_APPLICATION_MAIN(Magnum::Examples::TriangleExample)

• dpiScaling is reported as 1x1 in the SDL2 case, versus 2.97x3 in the glfw 3.4 case.
• I am running on NixOS 25.11 with Wayland + Niri compositor.

More visual example from our standalone robot visualizer mc_rtc-magnum built with magnum + imgui:

vs expected:

Both are running on NixOS 25.11, however the difference here is that:

• First screenshot is built from an in-tree version of magnum/glfw, with a much older glfw version from 4 years ago (~3.3.6): see https://github.com/mc-rtc/mc_rtc-magnum/tree/main/ext for all exact versions used
• Second screenshot is built against a standalone version of magnum built against glfw 3.4.0 (as packaged in nixpkgs) (cf PR Modularize - allow system dependencies mc-rtc/mc_rtc-magnum#4)
• same user code otherwise.

Are you aware of similar issues with glfw 3.4.0? What steps can I take to debug this further?

[mosra]

Hello, thanks for the detailed report!

Multiple things going on in here. First is that in both cases above, you're getting Platform: can't load X11 symbols for getting virtual DPI scaling, falling back to physical DPI. The background for that is described in #243 as you discovered already, in short the problem is that:

• On X11, both GLFW and SDL used to report a wildly incorrect DPI scaling value derived from display size in millimeters or some such, which was in most cases either wrongly reported by the display itself or wrongly manually put into xorg.conf. In other words, completely useless. That's the "physical DPI" described in docs, and it's the fallback value from the warning above.
• As a better solution, on X11 one can query the Xft.dpi property, which gives back the actual display scaling value as set by the user in the desktop environment, which is what I switched to for the default, "virtual DPI" setting. It's annoying, involves dlopen()ing X11 to avoid a hard link-time dependency, there's a lot of nasty corner cases (such as KDE not setting this property at all if it's exactly 100%, in which case I need to somehow detect that I'm on KDE and not fall back to the wildly incorrect physical DPI value), and, of course, this doesn't work on Wayland.
• Meanwhile, since 2018 when Correct out-of-the-box HiDPI support in SDL, GLFW and Android apps #243 was opened, both GLFW and SDL eventually managed to fix this and report the Xft.dpi value. So I could go back to using their APIs, unfortunately they also fall back to the (wildly incorrect) physical DPI in certain cases and I have no possibility of knowing whether the value I get is the correct or the wildly incorrect one, so, actually ... the APIs are still less reliable than doing it all myself. So what I'm missing is just the Wayland codepath.
• On Wayland, one has to ... well, I still don't know what all is involved, but Wayland isn't a library but rather a set of protocols described by XML files, and to query a literally four-byte value containing the DPI scaling one has to build a complex app that connects to a socket somewhere, maintains an event loop and deals with tens of async callbacks to enumerate capabilities and protocols and properties to actually get at this at all. And then there's the "builtin" non-fractional DPI scaling and then there's a "fractional scaling v1" protocol described in multiples of fractions of 1/120 for some reason, and I have to support both, and I just ... didn't manage to build enough courage to progress with any of this, so far. I cannot fathom how one can overengineer a display manager this much. (I could probably use something like libwayland to probably maybe get at this four-byte-value somehow easier but having it as a hard dependency would make X11-only users unhappy, which means dlopen()ing it again, but to my understanding one can't even expect libwayland to be present on a machine that runs Wayland, so I don't know if that's actually any easier than trying to send raw bytes over some socket.)

(Uh, long rambling. Sorry. I'm still running X11 here, trying to pretend these issues don't exist.)

Besides the Wayland-specific codepath missing on my end (implementing which would be the fix to all this), the behavioral difference you're seeing seems to be related to something new in GLFW 3.4, which makes it report a different scaling value somehow. The changelog says "support for Wayland fractional scaling", which is this commit so maybe that's what is breaking things in your case? Given that you have GLFW as a submodule you could maybe try pinning to one commit before instead of 3.4, and see if that changes anything? Changes in 3.3.10 to 3.3.6 don't seem to mention anything similar, but also there's over a thousand commits, so if the above commit isn't the root cause, one would need to run git bisect to find the right one. (There's also a bunch of open issues on the GLFW repo regarding Wayland and HiDPI / framebuffer size, and just seeing those makes me want to deal with Wayland even less 😅)

I assume you have display scaling at 100% on your end, right? In other words, GLFW < 3.4 and SDL do the correct thing, right?

Apart from the scaling issue on SDL vs GLFW I see also that the windows are using some completely different window decorations. Font being different size and weight, spacing also not the same... How is that even possible? Or is that some Gnome-specific thing I'm not aware of?

[arntanguy]

Thanks for the detailed answer, on a Sunday evening to boot ;)
Likewise, I do not like to deal with linux graphic stack, and its associated complexity, I just want windows that render consistently, unfortunately, that seems to be a harder problem than it looks. My interest lies elsewhere, in getting robots to move reliably around in the real world, which comes with its own set of issues 😅

Apart from the scaling issue on SDL vs GLFW I see also that the windows are using some completely different window decorations. Font being different size and weight, spacing also not the same... How is that even possible? Or is that some Gnome-specific thing I'm not aware of?

As far as I understand, client decorations used to be handled server-side by the window manager (kwin, etc) on X11, while they are done client-side on Wayland, essentially letting the apps draw their own decorations. Which as far as I could gather sdl does through a lib called libdecoration while glfw seems to have rolled its own. Hence the difference in style + the HiDPI rendering issue that messes up the scaling.

Anyhow, since you took the time for such a detailed answer, the least I could do was follow-up on it.

• Bisecting through GLFW and building my mc_rtc-magnum application against it led me to this commit: glfw/glfw@14e6533

14e653358bd46127931cf04aaba00d9f12cd03fa is the first bad commit
commit 14e653358bd46127931cf04aaba00d9f12cd03fa
Author: Camilla Löwy <elmindreda@glfw.org>
Date:   Thu Feb 15 20:55:28 2024 +0100

    Add support for XDG_SESSION_TYPE env variable

    Related to #2439

 README.md            |  1 +
 include/GLFW/glfw3.h |  7 +++++++
 src/platform.c       | 19 +++++++++++++++++++
 3 files changed, 27 insertions(+)

Fortunately that's a pretty simple commit:

+ *  @remark __Wayland, X11:__ If the library was compiled with support for both
+ *  Wayland and X11, and the @ref GLFW_PLATFORM init hint is set to
+ *  `GLFW_ANY_PLATFORM`, the `XDG_SESSION_TYPE` environment variable affects
+ *  which platform is picked.  If the environment variable is not set, or is set
+ *  to something other than `wayland` or `x11`, the regular detection mechanism
+ *  will be used instead.

...

+#if defined(_GLFW_WAYLAND) && defined(_GLFW_X11)
+    if (desiredID == GLFW_ANY_PLATFORM)
+    {
+        const char* const session = getenv("XDG_SESSION_TYPE");
+        if (session)
+        {
+            // Only follow XDG_SESSION_TYPE if it is set correctly and the
+            // environment looks plausble; otherwise fall back to detection
+            if (strcmp(session, "wayland") == 0 && getenv("WAYLAND_DISPLAY"))
+                desiredID = GLFW_PLATFORM_WAYLAND;
+            else if (strcmp(session, "x11") == 0 && getenv("DISPLAY"))
+                desiredID = GLFW_PLATFORM_X11;
+        }
+    }
+#endif

Now we're getting somewhere. Taking the last failing commit (14e6533) we get:

• echo $XDG_SESSION_TYPE -> wayland
• echo $WAYLAND_DISPLAY -> wayland-1
• mc_rtc-magnum -> wrong
• XDG_SESSION_TYPE="wayland" WAYLAND_DISPLAY="wayland-1" mc-rtc-magnum -> wrong
• XDG_SESSION_TYPE="" WAYLAND_DISPLAY="" mc-rtc-magnum -> good
• good:

unset XDG_SESSION_TYPE
unset WAYLAND_DISPLAY
mc-rtc-magnum

This works against glfw@master as well as 3.4.0 packaged in nix.
So I guess the the regular detection mechanism will be used instead works better than the custom logic ^^

I guess I'll take this up with them, thanks ;)

[mosra]

Do you have an idea where could the 300% scaling come from? Is that some compositor-specific setting that gets recognized by GLFW but doesn't by SDL? Unfortunately I don't know if there's a way to query such properties on a running Wayland compositor (some wayland info / wayland explorer app?). My other wild and poorly-informed guesses are:

• Something somewhere sets the "classic" integer DPI scaling to 3, and then the fractional DPI scaling to 1.0, and GLFW picks the integer value instead of the one coming from fractional-scale-v1
• Or it's the other way around, fractional DPI scaling is errorneously set to 3.0 and everything except GLFW ignores it

The commit you found seems just making the detection more robust, and I suspect that if you'd compile GLFW with Wayland only, it'd result in the same issue even with the env vars unset (or with GLFW before this commit).

[arntanguy]

Ouptut display configuration is done in Niri compositor's configuration file as:

// Internal monitor
output "PNP(CTO) 0x1115 Unknown" {
    mode "3840x2160"
    position x=0 y=0
    scale 2.25
}

// External monitor
output "Dell Inc. DELL P2719HC 9T8ZX13" {
    mode "1920x1080"
    position x=0 y=-1080
    scale 1.0
}

which is confirmed with niri msg outputs that shows

Output "Dell Inc. DELL P2719HC 9T8ZX13" (DP-1)
  Current mode: 1920x1080 @ 60.000 Hz (preferred)
  Variable refresh rate: not supported
  Physical size: 600x340 mm
  Logical position: 0, -1080
  Logical size: 1920x1080
  Scale: 1
  Transform: normal
  Available modes:
    1920x1080@60.000 (current, preferred)
    1600x900@60.000
    1280x1024@75.025
    1280x1024@60.020
    1152x864@75.000
    1024x768@75.029
    1024x768@60.004
    800x600@75.000
    800x600@60.317
    640x480@75.000
    640x480@59.940
    720x400@70.082

Output "PNP(CTO) 0x1115 Unknown" (eDP-1)
  Current mode: 3840x2160 @ 60.000 Hz (preferred)
  Variable refresh rate: not supported
  Physical size: 340x190 mm
  Logical position: 0, 0
  Logical size: 1706x960
  Scale: 2.25
  Transform: normal
  Available modes:
    3840x2160@60.000 (current, preferred)
    3840x2160@47.997

The screenshots above were generated running on my internal monitor ("PNP(CTO) 0x1115 Unknown" (eDP-1)), that indeed does have a 2.25 scaling defined, not too far off from the 3 detected.

I got curious, since the external monitor has a scaling of 1:

Wrong (external screen, 1080p, no scaling)

With XDG_SESSION_TYPE="wayland" WAYLAND_DISPLAY="wayland-1" (default), or XDG_SESSION_TYPE="" WAYLAND_DISPLAY="wayland-1", it's all messed up, but i noticed something:

When I first open the window, the horizontal stretch is odd. I think this may come from how niri handle its windows, it's a scrolling window manager: it usually starts with windows taking half the screen width, and you can resize them to full width (and scroll left-right out of the screen to switch to other windows, pretty nice).

1. Original full-screen window
   Here I did not resize the window, so according to how niri usually behaves, it should have taken half the screen, yet it took the whole screen. But it appears the viewport did not get the same info, looks like it's stretched as-if displayed on a window taking half the screen width. Now if i resize it to half-screen I get a robot model that looks normal, and imgui still messed up (differently)

2. Resized to half-screen, now the viewport proportion look correct, scaling is not (too big)

3. Resized to full screen again, viewport proportion looks correct, scaling is not

Correct (external screen)

With XDG_SESSION_TYPE="" WAYLAND_DISPLAY="" it's fine
Note that i did not zoom in or out in any of the window, they are as-displayed by the wayland compositor.

1. Windows initially open as half-screen width as expected

2. Recaled to full screen

3. Rescaled to half-screen is same as 1.

Wrong (internal screen, 4k, 2.25 scaling)

For completeness, here is the same wrong case on my internal screen with 2.25 scaling

Likewise rescaling to half-screen fixes the viewport proportions but not the scaling issues.

Conclusions

I'm starting to think that this is actually a compositor issue and that I should take it up with Niri, or a combination of Niri/Glfw issue. Even on a screen with a 1:1 scaling it behaves oddly, but only after the glfw/glfw@14e6533
Usetting XDG_SESSION_TYPE and WAYLAND_DISPLAY works both for my 4K internal screen with 2.25 scaling, and for my 1080p external screen with 1 scaling.
I'll try to see if I can reproduce on another compositor such as Hyprland.

[mosra]

So if you run the Magnum app with --magnum-dpi-scaling 2.25 explicitly set, does it look consistently scaled, or is the window also somehow stretched weirdly? (Or if you don't have arguments propagated to the application, setting MAGNUM_DPI_SCALING=2.25 in the environment works too.)

There isn't really anything done for multi-display support in Magnum (let alone multi-display with Wayland), so it's possible that it ends up detecting DPI scaling from one display but showing the window on another. And the 2.25x vs 3x difference could be just that 3 is the "non-fractional-scaling" fallback that GLFW ends up preferring for some reason. I suppose if you'd change to 1.75 for example, it would pick 2x scaling instead of 3x?

[arntanguy]

On the external screen (scaling = 1), with MAGNUM_DPI_SCALING="1" mc-rtc-magnum

initially messed up when the window first opens:

then after switching to half-screen then back to full screen it appears to be correct within the viewport, and still messed up for the window decorations:

On the internal screen (scaling = 2.25)

Still initially messed up, then after scaling back down and up

with MAGNUM_DPI_SCALING="2.25" mc-rtc-magnum

and with MAGNUM_DPI_SCALING="1" mc-rtc-magnum

Ah interestingly the grid seems to be the same size regardless of the scaling here, only imgui is changing

[mosra]

I didn't want to post a pointless "I have no idea" comment and then somehow two weeks passed, sorry.

With the DPI scaling detection sidestepped, I think there are two remaining things going on:

1. I never used a tiling WM / compositor, but I suspect that what it does is completely ignoring the application-specified window size and forcing its own, right? Which is likely what causes the "initially messed up" state. I.e., the application specifies that the size is, say, 800x600, times 2.25, so 1800x1350, and proceeds to create everything assuming that size. But due to the compositor the actual framebuffer and window size ends up being different and so it's messed up. Ideally either the actual framebuffer and window size reported by GLFW would match reality right from the beginning or, if not possible, a viewport event would be called immediately after construction to correct this, but somehow neither is happening and so this needs further investigation.
   • Assuming the compositor forces the window to be fullscreen, does Debug{} << windowSize() << framebufferSize(); in the constructor print the (correct) actual screen resolution or the (wrong) originally specified window size?
   • Without resizing the window to fix the messed up state, if you then print the same in the drawEvent(), does it report the same values as in the constructor?
   • I assume you don't get any viewportEvent() until you actually explicitly resize the window, right?
2. The DPI scaling affects size of the window and the framebuffer, and then it's passed to ImGui to affect size of the UI, which is what it's ultimately meant to do (same happens in the web version at https://magnum.graphics/showcase/imgui/ for example, it'll match the DPI scaling of the page itself). There it scales the contents as well as font size, and you have to explicitly take it into account when supplying custom fonts. Besides that, for anything else, it's up to the application to make use of the DPI scaling value or the framebuffer / window size ratio, and if you don't, then the DPI scaling value won't have any effect on your rendering, it'll be just drawing to a differently sized framebuffer. (Which is, now I realize, maybe the reason for the initial confusion with "a very low resolution window, scaled up multiple times bigger than expected" with the triangle example in the first post. From the screenshot the framebuffer resolution looks alright, it isn't blurry, just 3x larger due to the (mis)detected DPI scaling, and the only thing that's blurry is the messed up window decoration.)

I hope I managed to finally figure out what's going on and didn't add even more confusion to the whole thing 😅