#170 Wrong Windowsize and border in Win 7 x64


The values passed to reshapeFunction callback and the values received from glutGet is not correct. My understanding is that the width and height passed to the reshapeFunction callback should be the size of the drawable area (but even if it isn't the behavior is not consistent between differnet window states). Here is the results I get when the window is in normal state, maximized state, and fullscreen (width and height are the values pass to the reshapeFunction callback):

Normal Window:
drawableWidth = width – 8 = glutGet(GLUT_WINDOW_WIDTH) - 8
drawableHeight = height – 8 = glutGet(GLUT_WINDOW_WIDTH) - 8

Maximized Window:
drawableWidth = width = glutGet(GLUT_WINDOW_WIDTH) - 8
drawableHeight = height = glutGet(GLUT_WINDOW_HEIGHT) - 8

drawableWidth = width = glutGet(GLUT_WINDOW_WIDTH)
drawableHeight = height = glutGet(GLUT_WINDOW_HEIGHT)

- When the window is in normal state, width/height and is not the drawable width/height.
- When the window is maximized, width/height is not equal to glutGet(GLUT_WINDOW_WIDTH/HEIGHT)
- When the window is maximized, glutGet(GLUT_WINDOW_BORDER_WIDTH) = 4 when it should return 0

I am now using the following code to get the correct drawable area:

void reshapeFunction(int width, int height) {
glViewport (0, 0, width, height);


Another (probably related problem) is that going to and from fullscreen shrinks the windows size. I.e calling

glutFullScreenToggle(); glutFullScreenToggle();

shrinks both width and height with 8 pixels....

(I compiled and is running freeglut in x64 mode on Windows 7 64-bit x64)


  • John Mattsson

    John Mattsson - 2012-03-20

    When I reported the above bug, I used freeglut 2.80 and Visual Studio 11.

    I have now tested also tested the "Resizer" demo application in both x86 and x64 mode, with both freeglut 2.60 and 2.80 and compiled my own dlls and used the one from Martin Payne, and tested on different computers (all Win 7 x64). The results are the same:

    Resizer reports a size of 192x192 (It uses glutGet to get this info), but the drawable area when measured in Paint is only 184x184.

    Seems like quite serious bug (at least if you are doing 2D graphics), I assume this should have been noticed if it affected all variants of Windows, maybe it is only Win 7.

  • Diederick C. Niehorster

    Thanks for the report. I just tried on our current trunk, but as far as my memory serves me, the relevant parts didn't change much from the 2.8 release. I can't reproduce with either 32bit or 64bit builds running on windows 7 64bit, with MSVC2010.

    I always get a 200x200 window when the resizer demo starts, and repeatedly toggling fullscreen and back does not lead to a shrinking or expanding window

    the border size with a maximized not fullscreen) window is still 4, they are just offscreen (at least, i seem to remember that when running a dual monitor setup, don't have access to that now)

    Would you be willing to try current trunk (we're now using CMake as our build system) and asee if you still observe this?

  • Olaf van der Spek

    I think I'm hitting the same issue. The top and right are cut off in non-fullscreen mode. It's as if the app thinks the drawable area is equal to the full window size, not taking into account title bar and borders.
    I'm on W7, VC11.

  • John Mattsson

    John Mattsson - 2012-08-21

    Hi, I switched to Mingw-w64 (GCC 4.7.1) instead and then everything seems to work as expexted with version 2.8.0, The values passed to reshapeFunction equals glutGet(GLUT_WINDOW_WIDTH), glutGet(GLUT_WINDOW_WIDTH) and corresponds to the size of the drawable area.

    Seems like the problem is the new version of Visual Studio. As I have stopped using (uninstalled) Visual Studio I cannot check the current trunk. Somebody should check if the problem still exists in the release version of Visual Studio 2012 or if it the problem only occured in the beta (Visual Studio 11 Beta).

  • Diederick C. Niehorster

    Just to update, the problem indeed seems to be VS2012, which I just got access to. I'll have to investigate what's going different here...

  • Diederick C. Niehorster

    • status: open --> closed-fixed
  • Diederick C. Niehorster

    This should be fixed in r1394 now. I had written some code before to calculate client area and window size in a rather fragile way, I have used standard methods now and get consistent results across visual studio versions.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks