Maximising Window on x64 build

When running a standard GLFW Window on x86 platform.

Task: Resize window in windowed mode to full screen.
Observation: Memory usage stays the same about 20mb.

Problem: On x64 build platform.
Task: Resizing window in windowed mode to full screen.
Observation: Memory usage jumps from about 50mb to 160mb.

Has anyone had this problem before and if so could you please help me with this.

Kind regards,


Is this causing any problems?

What OS are you using?

Have you tracked down where the memory is being allocated (in the OpenGL driver, by GLFW, in your own code etc.)?

Thanks for the reply.

This is a a synthetic test, monitoring memory usage of a GLFW window on x86 build vs x64 build.

Using Windows 10 x64, with Visual Studio 14, however OS and IDE is irrelevant.

The problem seems to be the result of a window resize regardless of the size of the window.

Test Code in Question:

Have you tracked down where the memory is being allocated (in the OpenGL driver, by GLFW, in your own code etc.)

Any suggestions would be much appreciated.

Kind regards,


Hi Adam,

Since you’re program is a synthetic test to monitor memory usage, and you’ve successfully run and monitored memory usage, it seems to me you don’t have a problem other than an interest in trying to understand what’s going on.

The OS and compiler toolchain are actually quite important.

Since you’re using Visual Studio 2015 (VS 14.0) you can use the memory heap profiling tool to investigate. Run your program and take a snapshot just before you resize, and then resize and take another snapshot so you can look at the difference. Make sure that you have debug information in your build (i.e. a release build but generating a pdb) and that you’re targeting the v140 platform toolset (this should be standard).

In my case what I see is that although the memory of the process changes when I change the size of the window or go fullscreen, the application itself and glfw are not allocating any memory as the heap snapshots show.

Using Process Explorer I can see that the GPU memory is going up at the same time as the overall Private Data, so it’s probable that the driver or WDDM is responsible. Looking at the 32 bit build I see that although the GPU memory increases, the private data doesn’t go up much.

You might wonder why there’s a difference between the 32 and 64 bit versions, and it’s possible this is related to an issue we encountered when working on Crysis DX10 and WDDM 1.0 which led to a Microsoft releasing a QFE patch - video memory was being virtually mapped in the process virtual space leading to the process running out of virtual memory. Since 64bit memory space is more than sufficient, the memory optimization may not be applied on 64bit processes. This is a guess however.

In conclusion you don’t need to worry about this.

Hi Doug,

Thanks for that explanation, however I am looking for a concrete answer, instead of conjecture and speculation.

Thank you for your time and analysis.

Kind regards,


Hi Adam,

The best way for a more concrete answer than that provided is to investigate this yourself. I’ve linked to some of the tools with which you can do this. There are further tools available such as ETW tracing and GPUView, VMMap and RAMMap.

Good luck.




However comparing against an SDL2 window (same scenario as above), there is no memory leak appearing on the resizing of the window.

This would suggest that there may in fact be a problem within the GLFW framework (hard to believe).

I suggest this should be looked into.

If I may be directed to a maintainer that would deal with such an issue, it would be greatly appreciated.

Kind regards,


Did the SDL window have an OpenGL context?


As I said above, exact same context as above test, however implementing SDL 2 to create the window etc.

What .h / .c files pertain to handling the resize of a GLFW window, if I may have a look at them.

Kind regards,


So first of all, please stop being rudely dismissive of advice you asked for. You wanted to speak to a maintainer? Hello. Listen to what @dougbinks said. That is by far the most likely cause.

Your test code is a broken link to an image. Please post the actual code instead, and the corresponding SDL code.

Win32 window handling is in the win32_window.c file.

Thanks for the reply,

Unfortunately, useless dribble is not worth my time.

However, you should look into your memory leak issue, as it IS very poor form.

Kind regards,


Hi Adam,

There is no memory leak from GLFW as per my earlier reply.



I’ve blocked user rNdm74 for being rude once again after having been warned.