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 ;)