How to draw while resizing GLFW window?

Question

Whenever I resize a GLFW window it doesn't draw while I'm resizing the window. The newly exposed part of the window only gets drawn on after I finish resizing the window. You can see it for yourself in the picture below:

Here is the code for my application. I am running Windows 10 on Visual Studio 2015

#include <glad/glad.h>
#include <GLFW/glfw3.h>
#include <iostream>

void framebuffer_size_callback(GLFWwindow* window, int width, int height);
void processInput(GLFWwindow *window);
void get_resolution(int* window_width, int* window_height);
void initGlfwSettings();
GLFWwindow* initGlfwWindow();
void initGlad();

// settings
const unsigned int SCR_WIDTH = 800;
const unsigned int SCR_HEIGHT = 600;

int main()
{
    initGlfwSettings();

    GLFWwindow* window = initGlfwWindow();

    initGlad();

    // glad: load all OpenGL function pointers
    // ---------------------------------------


    // render loop
    // -----------
    while (!glfwWindowShouldClose(window))
    {
        int width, height;
        glfwGetWindowSize(window, &width, &height);


        glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
        glClear(GL_COLOR_BUFFER_BIT);

        glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);
        // input
        // -----
        processInput(window);

        // glfw: swap buffers and poll IO events (keys pressed/released, mouse moved etc.)
        // -------------------------------------------------------------------------------
        glfwSwapBuffers(window);
        glfwPollEvents();
    }

    // glfw: terminate, clearing all previously allocated GLFW resources.
    // ------------------------------------------------------------------
    glfwTerminate();
    return 0;
}

// process all input: query GLFW whether relevant keys are pressed/released this frame and react accordingly
// ---------------------------------------------------------------------------------------------------------
void processInput(GLFWwindow *window)
{
    if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)
        glfwSetWindowShouldClose(window, true);
}

// glfw: whenever the window size changed (by OS or user resize) this callback function executes
// ---------------------------------------------------------------------------------------------
void framebuffer_size_callback(GLFWwindow* window, int width, int height)
{
    // make sure the viewport matches the new window dimensions; note that width and 
    // height will be significantly larger than specified on retina displays.
    glViewport(0, 0, width, height);
}

void get_resolution(int* window_width, int* window_height) {
    const GLFWvidmode * mode = glfwGetVideoMode(glfwGetPrimaryMonitor());

    *window_width = mode->width;
    *window_height = mode->height;
}

void initGlfwSettings()
{
    // glfw: initialize and configure
    // ------------------------------
    glfwInit();
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
    glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);


    #ifdef __APPLE__
        glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); // uncomment this statement to fix compilation on OS X
    #endif
}

GLFWwindow* initGlfwWindow()
{
    /*GLFWmonitor* monitor = glfwGetPrimaryMonitor();
    int width;
    int height;

    get_resolution(&width, &height);*/



    GLFWwindow* window = glfwCreateWindow(SCR_WIDTH, SCR_HEIGHT, "learning opengl", NULL, NULL);
    if (window == NULL)
    {
        std::cout << "Failed to create GLFW window" << std::endl;
        glfwTerminate();
        exit(1);
    }

    glfwMakeContextCurrent(window);
    glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);
    glfwSwapInterval(1);

    return window;
}

void initGlad()
{
    if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))
    {
        std::cout << "Failed to initialize GLAD" << std::endl;
        exit(1);
    }
}

Explain any solutions to this problem.

Haematozoon

Does this answer your question? GLFW poll waits until window resize finished, how to fix? – Weber

@Andreasdetestscensorship IMO it's better to ask to close the other question than this one which has more vote and better answers. You should more check for which post do you flag instead of simply ask for duplicate of multiple posts – Solicitude

@Solicitude I found the other question to be better, and this question to only have 1 good answer. As such, I picked the oldest question as a duplicate target. These questions can be merged. – Weber

Answer 1

Event processing (glfwPollEvents) stalls whenever the window is resized, but while doing so, it constantly emits resize events, which are processed on the fly by the resize callback that you already use. You can redraw your scene from there and call glfwSwapBuffers to render even when in glfwPollEvents. Practically speaking, this can be achieved by the following code:

void draw()
{
    // Rendering code goes here
    glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);
    glfwSwapBuffers(window);
}

void framebuffer_size_callback(GLFWwindow* window, int width, int height)
{
    // make sure the viewport matches the new window dimensions; note that width and 
    // height will be significantly larger than specified on retina displays.
    glViewport(0, 0, width, height);
    // Re-render the scene because the current frame was drawn for the old resolution
    draw();
}

and move your rendering (glClearColor, glClear and glfwSwapBuffers) from the main loop into draw. Leave a call to draw in your main loop and make window a global variable or pass it to draw when calling it, else it'll be out of scope in draw, where it's needed for glfwSwapBuffers.

That only works when the user moves the mouse while holding - just holding left-click on the resize window part still stalls. To fix that, you need to render in a separate thread in addition to this. (No, you can't do that without threading. Sorry, this is how GLFW works, no one except them can change it.)

Sanction

"To fix that, you need to render in a separate thread in addition to this." Does this imply making the GL context current and then detaching it every time you draw on either thread? Otherwise, how would you be able to draw in both the render loop and within the resize callback? – Stanislas

From a bit of testing, it looks like it's best for the resize callback to request a ctx switch from the render loop, so the render loop doesn't have to worry about ctx switching under "normal" operation (i.e. no resizing). This solution potentially burns a lot of CPU cycles during resizing, but...who cares. Resizing isn't normal operation and this solution provides perfectly smooth resizing without fussing over the peculiarities of the SIZEMOVE loop. – Stanislas

I'd like to add a comment here: at least on my machine (Windows 10), the frame resize callback will be called before the window resize callback. This can lead to very short-lived discrepancies between the two until the window resize callback is called. So if there's any drawing code that makes use of the ratio between frame buffer size and window size it could lead to weird graphical glitches. Maybe it's best to draw in the window resize callback while taking the last saved frame buffer size from the frame resize callback? – Biome

Answer 2

Edit: the following answer is nice and all and works, but sadly it is not the perfect solution for this, however it is still a solution if you want to use it

I'm surprised no one mentioned window refresh callback, which is the method documented by GLFW for this specific issue, from documentation of glfwPollEvents() link :

On some platforms, a window move, resize or menu operation will cause event processing to block. This is due to how event processing is designed on those platforms. You can use the window refresh callback to redraw the contents of your window when necessary during such operations.

to be fair it is a bit buried, and I myself wasn't able to find it a while ago

void window_refresh_callback(GLFWwindow *window)
{
    render();
    glfwSwapBuffers(window);
    glFinish(); // important, this waits until rendering result is actually visible, thus making resizing less ugly
}

note that for this to work properly glViewport() must be called somewhere

void framebuffer_size_callback(GLFWwindow *window, int width, int height)
{
    glViewport(0, 0, width, height);
}

in your GLFW setup code:

// rest of code
glfwSetWindowRefreshCallback(window, window_refresh_callback);
glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);
// rest of code

with previous edits I found that resizing is more stable, even more stable than rendering in the window resize callback, even with glFinish there, you can also compare the behavior of your application with software like Blender

I also have the following in my GLFW initialization code as instructed by GLFW documentation to reduce tearing: https://www.glfw.org/docs/latest/quick.html#quick_swap_buffers

glfwSwapInterval(1);

Arcane

Unfortunately (at least on my system, Win11), this callback is not called when moving the window. For this I had to also use glfwSetWindowPosCallback – Bigler

Thanks for this. It works. May I know why its not a 'perfect' solution. (I am an OpenGL beginner). – Robert

Anytime Hash, I'm also kind of a begginer in that sense, I think there maybe actually no perfect solution, major programs also have some sort of delay, even if smooth, between resized window and content, the only two good solutions I found are Qt GUI framework and Flutter, but this doesn't help with making a game or graphics application, I guess we have to live with the fact that it will never be perfect, to improve the situation more we might introduce threads – Arcane

Answer 3

It's the windows event handler not returning control to the main thread. Its how windows works and you can't change it.

You can however move all your rendering and glfw commands to a different thread, which won't be stalled by windows.

Northbound

It's usually a good thing, that the controll is only returned when resizing is finished, because you often have framebuffers that are the same size of the window. These have to be only resized once when the resizing is finished. – Brattice

I've only ever wanted to keep updating in everything I've built. Things like like running video or live data, at bare minimum the capture needs its own thread to avoid stalls. – Northbound

@JonathanOlson how exactly would you implment this? I tried twice to implement it myself and once everything displayed but the loading cursor would always be displayed. On my second try a black screen displayed. – Haematozoon

There's a brief discussion here that might help. sourceforge.net/p/glfw/discussion/247562/thread/2e6e361e – Northbound

@JonathanOlson I converted his code to code using std::thread. It displays a triangle but when resized the window doesn't update. Source code here – Haematozoon

In addition to being incomplete, it looks like that code only runs the rendering steps once, not in a loop. It doesn't update while resizing because it doesn't update (unless there's more rendering code in the missing class member function). – Northbound

Answer 4

You do not need to set up a separate thread.

You just need to handle the WM_SIZE message and repaint when it happens, which can be accessed by using the glfwSetWindowSizeCallback function. You can call everything inside the loop, or just call the render and swap buffers parts.

Windows does not return from message processing while a drag operation is going on, but will continue to process events. So you just need to do whatever you would have done each frame inside the callback, plus enough to reconfigure your viewports and matrices and whatnot for any new client size. This principle also works for window moves or anything similar.

For Win32 or glfw the basic flow is:

void MyStart()
{
  for glfw set the callback to MyCallback via glfwSetWindowSizeCallback

  while(!ShouldExit)
  {
    some code
    MyFrame()
  }
}

void MyFrame()
{
  do things I normally do per frame

  paint this and that

  swap buffers
}

void MyCallback()
{ 
    get new client area size
    reset viewport or fov
    MyFrame();   
}

// for windows without glfw
void WndProc()
{
  WM_SIZE:
    MyCallback();
}

Bakerman

Still stops updating/drawing while the mouse isn't moving during a resize, at least on Windows 7 with GLFW 3.2.1. – Ponytail

@Ponytail Check to see if the callback is actually firing when you drag a resize handle. The rest should just be drawing. See if this helps: forum.lwjgl.org/index.php?topic=6090.0 – Bakerman