Improving window resize behaviour, possibly by manually setting bigger framebuffer size

Question

I was considering using glfw in my application, while developing on mac

After successfully writing a very simple program to render a triangle on a colored backround, I noticed that when resizing the window, it takes quite some time to rerender the scene, as I suspect due to framebuffer resize.

This is not the case when I am repeating the experiment with NSOpenGLView. Is there a way to hint glfw to use bigger framebuffer size on start, to avoid expensive resizes?

I am using GLFW 3.

Could you also help me with enabling High DPI for retina display. Couldn't find something in docs on that, but it supported in version 3.

Sambo

The default framebuffer of the GL is the "window-system provided framebuffer", which is totally out of the control of the GL and managed by the window system/operation system. So if there were a way to change that, you would have to look for platform specific functions for your OS/window system. I don't know about any such feature on any platform, but I haven't looked for such a thing. – Trochal

I tried to do the same thing with native Cocoa apis, and resizing was very smooth. so possibly an improvment to glfw could be made – Sambo

As far as I know, whole point of using GLFW is to get help with the window management and OpenGL content creations. Therefore, I don't think that it would be easy to change resize methods. You might be needed to go very low-level in coding. – Cammiecammy

Does it take some time to re-render the scene even if you re-size to a smaller window OR does this happen ONLY if you re-size to a bigger window size than the original? – Burget

Always, it seems like its not doing any rerendering until you let go the mouse while resizing the window. – Sambo

Ok. That's easily explained. The render pipeline stalls during resize(and window drag) because the window manager blocks. You should try installing your own handler functions for window msgs and running the render pipeline in a separate independent thread. You might want to take a look at this "ancient" thread that discusses the same issue with GLFW on Windows in detail. – Burget

This sounds like a case of the XY problem – Deuteron

Answer 1

Obtaining a larger framebuffer

Try to obtain a large initial frame-buffer by calling glfwCreateWindow() with large values for width & height and immediately switching to displaying a smaller window using glfwSetWindowSize() with the actual initial window size desired.

Alternately, register your own framebuffer size callback function using glfwSetFramebufferSizeCallback() and set the framebuffer to a large size according to your requirement as follows :

void custom_fbsize_callback(GLFWwindow* window, int width, int height)
{
    /* use system width,height */
    /* glViewport(0, 0, width, height); */

    /* use custom width,height */
    glViewport(0, 0, <CUSTOM_WIDTH>, <CUSTOM_HEIGHT>);
}

UPDATE :
The render pipeline stall seen during the window re-size(and window drag) operation is due to the blocking behavior implemented in the window manager.

To mitigate this in one's app, one needs to install handler functions for the window messages and run the render pipeline in a separate thread independent from the main app(GUI) thread.

---

High DPI support

The GLFW documentation says :

GLFW now supports high-DPI monitors on both Windows and OS X, giving windows full resolution framebuffers where other UI elements are scaled up. To achieve this, glfwGetFramebufferSize() and glfwSetFramebufferSizeCallback() have been added. These work with pixels, while the rest of the GLFW API work with screen coordinates.

AFAIK, that seems to be pretty much everything about high-DPI in the documentation.

Going through the code we can see that on Windows, glfw hooks into the SetProcessDPIAware() and calls it during platformInit. Currently i am not able to find any similar code for high-DPI support on mac.

Burget

How would one invoke glfwSetFramebufferSizeCallback before creating the window. If I'm not mistaken this function must be passed window whose callback should be set. – Jag

@Jag Good catch. Fixed the mistake in the answer. – Burget