High CPU usage when GLFW / OpenGL Window isn't visible

Question

I'm using GLFW so set up a Window with OpenGL. As i'm just started learning OpenGL and all the stuff around it, this might sound like a silly question, but why is the example program of GLFW using nearly 100% CPU when the Window is not actively displayed (minimized or hidden by another Window)?

Here is the GLFW exmaple, i'm running it on Mac OS with Xcode:

#include <GLFW/glfw3.h>
int main(void)
{
    GLFWwindow* window;

    if (!glfwInit())  /* Initialize the library */
        return -1;

/* Create a windowed mode window and its OpenGL context */
    window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
    if (!window)
    {
       glfwTerminate();
        return -1;
    }

/* Make the window's context current */
    glfwMakeContextCurrent(window);

/* Loop until the user closes the window */
    while (!glfwWindowShouldClose(window))
    {
        /* Render here */

        /* Swap front and back buffers */
        glfwSwapBuffers(window);

        /* Poll for and process events */
        glfwPollEvents();
    }

    glfwTerminate();
    return 0;
}

Answer 1

Your render loop is executed no matter what mimimization state of your window is.

If you want to stop rendering, you have to enhace the application logic a bit to track the state your window is in. GLFW supports user-defined a callback for such things with glfwSetWindowIconifyCallback() so your application can get noticed when the window is minimized or restored. You can the decide to stop the render loop, and can use glfwWaitEvents() to wait for something to happen (like the window being restored) without using all available CPU time.

Answer 2

Maybe start doing something?

Or use glfwWaitEvents(); instead of glfwPollEvents(); to block when there isn't new events.

The documentation explains it on the first step : http://www.glfw.org/docs/latest/quick.html

Answer 3

NSOpenGLContext::flushBuffer is non blocking if the window is not visible to the user (for instance, there another window in front of it). Since glfwSwapBuffers does just call this function, it becomes non blocking in this situation. I'm not sure what options we have to avoid consuming 100% CPU in this case, except using a Core Video display link.

From here: https://github.com/glfw/glfw/issues/680

OS X ignores the NSOpenGL swap interval when the window is obscured. No other OS does this. I will look into working around this with display link at some point. If that doesn't work, I don't think there's anything GLFW can do.