Smoothly changing window size with SetWindowSize?

[rossberg]

Is there any way of calling SetWindowSize on an active window without creating frame artefacts?

I have a windowed application which allows opening/closing certain parts of the UI interactively, resulting in a changed window size (and sometimes position). Unfortunately, after SetWindowSize, the window content is visibly garbled for at least the remaining frame (depending on platform, it either moves or scales the current content instantly). That looks rather unprofessional.

There does not seem to be a means of synchronising resizing with framebuffer swaps. I tried various workarounds, including combinations of:

• different timings for calling SetWindowSize before or after EndDrawing/SwapBuffer,
• turning off FPS wait,
• delaying resizing by one frame during which I draw to a texture as custom frame buffer of the new size, such that it can be copied and swapped in immediately after resize.

None of it helped much, the artefact frames remain, at least some of the times.

Has anybody else run into this problem and found a workable solution (on GLFW or other backend)?

[mallory-scotton]

The artifact is a timing problem between the OS window manager and the OpenGL swap chain, not a raylib bug.

When SetWindowSize runs, the window manager resizes the window rectangle and fires a synchronous repaint. The compositor reads whatever is in the front buffer right at that moment, before your next frame has rendered. glfwSwapBuffers doesn't fire until EndDrawing() finishes, so the OS grabs the old, wrong-sized buffer and stretches or garbles it to fill the new bounds. Shuffling when you call EndDrawing can't help, by the time you get there, the damage is done.

One caveat worth knowing: on Wayland, glfwSetWindowSize is just a request to the compositor. The actual resize and the callback both happen asynchronously, so the approach below won't work there. This is primarily a Windows and X11 fix.

The workaround is to hook GLFW's window size callback and push a complete new frame before the compositor reads the buffer:

#include "raylib.h"
#include "rlgl.h"
#include <GLFW/glfw3.h>

GLFWwindowsizefun originalWindowSizeCallback = NULL;

void DrawUI();

void CustomWindowSizeCallback(GLFWwindow* window, int width, int height) {
    // Let raylib update its internal CORE.Window.screen state first
    if (originalWindowSizeCallback) originalWindowSizeCallback(window, width, height);

    // Render before the OS compositor reads the buffer
    BeginDrawing();
    DrawUI();

    // Don't call EndDrawing(), it calls glfwPollEvents() internally,
    // which is undefined behavior inside a GLFW callback and tends to crash.
    // Flush and swap manually instead:
    rlDrawRenderBatchActive();
    glfwSwapBuffers(window);
}

void DrawUI() {
    ClearBackground(RAYWHITE);
    DrawText("No more artifacts!", 10, 10, 20, DARKGRAY);
    // ... the rest of your UI
}

int main(void) {
    InitWindow(800, 600, "Smooth Resize Solution");

    GLFWwindow* glfwWindow = (GLFWwindow*)GetWindowHandle();
    // Chain callbacks so raylib's internal handler still runs
    originalWindowSizeCallback = glfwSetWindowSizeCallback(glfwWindow, CustomWindowSizeCallback);

    while (!WindowShouldClose()) {
        if (IsKeyPressed(KEY_SPACE)) {
            SetWindowSize(1024, 768);
        }

        BeginDrawing();
        DrawUI();
        EndDrawing();
    }

    CloseWindow();
    return 0;
}

On HiDPI or Retina displays, also hook glfwSetFramebufferSizeCallback, physical pixel counts don't always match screen coordinates, and you'll want both covered.

[rossberg]

Thanks @mallory-scotton, that is very helpful!

The artifact is a timing problem between the OS window manager and the OpenGL swap chain, not a raylib bug.

Yes, that was my understanding. I'd call it a "missing feature" of sorts, not a bug. My feature wish would be Raylib somehow exposing this kind of functionality without having to drop down to backend-specific and non-portable code.

One caveat worth knowing: on Wayland, glfwSetWindowSize is just a request to the compositor. The actual resize and the callback both happen asynchronously, so the approach below won't work there. This is primarily a Windows and X11 fix.

Ah, that's unfortunate.

The workaround is to hook GLFW's window size callback and push a complete new frame before the compositor reads the buffer:

Thanks for the code sample, this should help (if I somehow manage to get access to the callback through the binding I'm using). Quick question: Is there a reason not to use SwapScreenBuffer as a slightly higher-level API call?

[raysan5]

@mallory-scotton did you test it? does it work? I'll be surprised because provided code is incorrect... GetWindowHandle() does not return a GLFWwindow* pointer... what raylib version are you using?

[mallory-scotton]

You caught me, I actually haven't had a chance to test this code directly yet. It was a quick conceptual workaround I scribbled down to address the compositor timing issue, and I completely blanked on the fact that GetWindowHandle() doesn't just hand back the raw GLFWwindow*.

Definitely a classic 'looks right on paper' mistake on my part. If we get the actual GLFW context handle, do you think forcing the manual buffer swap inside the callback is a viable path forward for the resizing artifact?

[raysan5]

Not sure... definitely it should be tested... and probably getting different results on different OSs and different windowing sytems...