Race-condition when calculating framebuffer-scale on X11

[TheBrokenRail]

Version/Branch of Dear ImGui:

master (02af06ea5f57696b93f0dfe77a9e2525522ba76e)

Back-ends:

imgui_impl_glfw.cpp + imgui_impl_opengl2.cpp

Compiler, OS:

Ubuntu 24.10, GNOME XWayland, GCC 14.2.0

Full config/build information:

No response

Details:

My Issue/Question:

ImGui_ImplGlfw_GetWindowSizeAndFramebufferScale divides the framebuffer size by the window size to get the framebuffer scale. To do this, it uses glfwGetWindowSize and glfwGetFramebufferSize. On X11, glfwGetFramebufferSize just calls glfwGetWindowSize (because X11 does not support scaling). glfwGetWindowSize makes a call to XGetWindowAttributes.

It is possible (albeit rare) for the window size to change between these two calls. This will causes a non-1.0 scale to bet set on X11, which should never happen. Most of the time, the scale will momentarily be set to something like (0.725169, 0.745940) before being immediately corrected. But sometimes, it will get set to extremely erroneous values like (1123.000000, 0.894057), causing a crash.

I don't know if this happens on "real" X11, but it definitely happens on GNOME's XWayland implementation.

Steps To Reproduce

1. Apply the following patch:

   --- a/backends/imgui_impl_glfw.cpp
   +++ b/backends/imgui_impl_glfw.cpp
   @@ -919,6 +919,9 @@ void ImGui_ImplGlfw_NewFrame()
    
        // Setup main viewport size (every frame to accommodate for window resizing)
        ImGui_ImplGlfw_GetWindowSizeAndFramebufferScale(bd->Window, &io.DisplaySize, &io.DisplayFramebufferScale);
   +    if (io.DisplayFramebufferScale.x != 1.0f || io.DisplayFramebufferScale.y != 1.0f) {
   +        fprintf(stderr, "Scale: %f %f\n", io.DisplayFramebufferScale.x, io.DisplayFramebufferScale.y);
   +    }
    
        // Setup time step
        // (Accept glfwGetTime() not returning a monotonically increasing value. Seems to happens on disconnecting peripherals and probably on VMs and Emscripten, see #6491, #6189, #6114, #3644)

2. Run XDG_SESSION_TYPE=x11 ./example_glfw_opengl2 (this will force it to use XWayland/X11).
3. Start resizing the window like your life depends on it.
4. Pay attention to the invalid scales being printed to the terminal.

Solution

X11 doesn't support HiDPI, just add a if (glfwGetPlatform() == GLFW_PLATFORM_X11) check and return (1.0, 1.0).

Screenshots/Video:

With V-Sync (The Default)

Screencast.From.2025-09-06.02-31-01.webm.crushed.mp4

Without V-Sync

Screencast.From.2025-09-06.02-44-39.webm.crushed.mp4

Minimal, Complete and Verifiable Example code:

No response

[ocornut]

It is possible (albeit rare) for the window size to change between these two calls.

(1) I don't think this assumption made it is what is causing the issue. It would be magnitude more unlikely to happen the way it is happening if the issue was that the window size changed between these two calls.

The issue seem related to the fact that framebuffer size is not updated at the same time as window size, which at this point should be solely a GLFW issue because we don't control this.

• What's your GLFW version?
• Can you print raw values for (A) glfwGetWindowSize() (B) glfwGetFramebufferSize() and result (C) FrameBufferScale using IMGUI_DEBUG_LOG() so we can also see frame timing of how both value evolve?

But sometimes, it will get set to extremely erroneous values like (1123.000000, 0.894057), causing a crash.

(2) An extremely erroneous value would indeed request an abnormally dense font and would likely crash.
Can you please clarify where it is crashing? (assert/callstack) to ensure I am right about my understanding of this?

Surprisingly, even though an incorrect io.DisplayFramebufferScale (which I would like to fix of course) would affect your application, it should do it in a hardly noticeable way in this situation (apart from the crash, of course). It will mess with font density, and it may temporarily break clip rectangle scaling. But I'm not entirely sure that the "visual" issues you are seeing are related to this value being wrong, only the crash is.

(3) Can you try to clear this value right after calling ImGui_ImplGlfw_NewFrame():

ImGui_ImplGlfw_NewFrame();
ImGui::GetIO().FrameBufferScale = ImVec2(1.0f, 1.0f);

• Can you confirm that this fixes the occasional crash ?
• How does resizing the window now looks? It is the same or better? (I would assume it is the same)

[TheBrokenRail]

The issue seem related to the fact that framebuffer size is not updated at the same time as window size, which at this point should be solely a GLFW issue because we don't control this.

The framebuffer size isn't tracked separately at all. On X11, glfwGetFramebufferSize is literally just:

void _glfwGetFramebufferSizeX11(_GLFWwindow* window, int* width, int* height)
{
    _glfwGetWindowSizeX11(window, width, height);
}

And glfwGetWindowSize just makes a call to XGetWindowAttributes:

void _glfwGetWindowSizeX11(_GLFWwindow* window, int* width, int* height)
{
    XWindowAttributes attribs;
    XGetWindowAttributes(_glfw.x11.display, window->x11.handle, &attribs);

    if (width)
        *width = attribs.width;
    if (height)
        *height = attribs.height;
}

The values are not cached or stored at all.

What's your GLFW version?

I'm using master, but specified functions are the same in old versions like 3.2.

Can you print raw values for (A) glfwGetWindowSize() (B) glfwGetFramebufferSize() and result (C) FrameBufferScale using IMGUI_DEBUG_LOG() so we can also see frame timing of how both value evolve?

Here you go!

Here is an example of the bug:

Window Size: [2101, 869], Framebuffer Size: [2101, 869], Framebuffer Scale: [1.000000, 1.000000]
Window Size: [2101, 869], Framebuffer Size: [2101, 869], Framebuffer Scale: [1.000000, 1.000000]
Window Size: [2101, 869], Framebuffer Size: [2101, 67], Framebuffer Scale: [1.000000, 0.077100]
Window Size: [2101, 67], Framebuffer Size: [2101, 67], Framebuffer Scale: [1.000000, 1.000000]
Window Size: [2101, 67], Framebuffer Size: [2101, 67], Framebuffer Scale: [1.000000, 1.000000]

An extremely erroneous value would indeed request an abnormally dense font and would likely crash.
Can you please clarify where it is crashing? (assert/callstack) to ensure I am right about my understanding of this?

Yeah, it just seems to be running out of memory:

example_glfw_opengl2: ../../imgui_draw.cpp:4672: bool ImGui_ImplStbTrueType_FontBakedLoadGlyph(ImFontAtlas*, ImFontConfig*, ImFontBaked*, void*, ImWchar, ImFontGlyph*, float*): Assertion `pack_id != -1 && "Out of texture memory."' failed.
Aborted (core dumped)

And, in my opinion, if someone tries to render with a framebuffer scale of [675.000000, 4.240838], then it should absolutely crash because I can not think of a situation where that would ever be correct.

It will mess with font density, and it may temporarily break clip rectangle scaling. But I'm not entirely sure that the "visual" issues you are seeing are related to this value being wrong, only the crash is.

By "visual issues" I just meant that for a single frame it would be rendered with an odd scaling value. It's not noticeable. The real issue is that the scaling values are wrong in the first place (and sometimes wrong enough to crash).

ImGui::GetIO().DisplayFramebufferScale = ImVec2(1.0f, 1.0f);

This does fix the crash, because it override the invalid scale. But it also breaks framebuffer scaling on Wayland.

[ocornut]

Here you go!
Here is an example of the bug:

Thanks! My apologies I had somehow overlooked the fact (even though it's actually pretty clear from the first video) that the issue is "rare" enough and indeed feels like a race condition or some sort. Somehow I thought you were mostly disturbed about the frame buffer distortion (which is a whole different issue).

Yeah, it just seems to be running out of memory:
And, in my opinion, if someone tries to render with a framebuffer scale of [675.000000, 4.240838], then it should absolutely crash because I can not think of a situation where that would ever be correct.

Thanks for confirming that side effect, as expected. Yes, the crash is "fine" here, and we should strive to fix the framebuffer.

I have not yet fully caught up with #8921 but I imagine a workaround may indeed that we make ImGui_ImplGlfw_GetWindowSizeAndFramebufferScale() output 1.0f/1.0f for framebuffer_scale when glfwGetPlatform() == GLFW_PLATFORM_X11 (requires 3.4).
I'll confirm this after catching up with the other thread.

[ocornut]

I posted what I believe are the fixes for GLFW backend:

• added ImGui_ImplGlfw_IsWayland() helper + minor tweaks to align with docking branch 10d0162
• main commit 2675b7c

Please confirm 🙏

[ocornut]

@TheBrokenRail Before closing this issue, could you confirm that you are not getting the same glitch on SDL2 and SDL3 examples?

[TheBrokenRail]

I tested with SDL2 and the issue does not seem to occur! It also seems fixed with GLFW.