SwapBuffers(), Wnd size and FPS drop

Hi everyone!

This is my first post and i’m not english, just hope i can describe my problem clearly enough for you to understand…

I run windows vista and my OpenGL version is 2.1, i can’t remember che gpu vendor and model but if you need them i can check them and write them down here.
Anyway…i’ve got an OpenGL program, just a small one actually, with a simple message loop (PeekMessage), a couple of rendering calls, a call to SwapBuffers and an FPS counter (very simple, just an int counter that tells me its value every 1000 ms and then resets itself).

When I run the program, the window appears at the upper-left corner of the screen, with a size of 640x500 pixels (that’s right, i told it to do so!) and my FPS counter shows approx 600 fps.
Then I begin resizing my window, and i resize it until its lower-right corner is almost at the lower-right corner of the screen…let’s say i leave 1 pixel of screen to the right and down the window; in the process, my FPS count goes down gradually until it reaches, when i’m 1 pixel from the end, approx 400 FPS, and it goes on showing me that value if i stop resizing the window and leave it alone (and that’s ok, i expected it).
But, and here comes the problem, if i resize it 1 pixel more to che right and down (i cover all my screen with the window) the FPS count INSTANTLY drops from 400 to 70 FPS, and it does not come back to 400.
If, again, i resize my window 1 pixel to the left-up, so that it does not cover the whole screen any more, the FPS count comes instantly back to 400 FPS.

The same happens if i maximize the window: when it’s maximized, the FPS count drops to 70-80 fps, and if i de-maximize (sorry, i don’t know how to tell that :D) it again, the FPS count comes back again to 400 FPS.

As far as you know, is there a rational explanation to the issue, ad possibly a solution?

Ok i did further tests…

The FPS count drop to 70 fps actually has nothing to do with the WIDTH of the window, but only with its HEIGHT.
As long as i keep the lower border of the window away from che lower end of the screen (the programs bar, even just 1 pixel away), no matter the width of the window, the FPS count is 400 fps or more

But as soon as the lower border of the window touches the task bar (or program bar, i don’t know how you call it :slight_smile: ), the FPS count drops instantly to 70-80 fps, no matter if the width of the window is 1200, 500 or even 100 pixels…

hope this can help!

What’s happening when you resize your window is that the backbuffer remains at the same size as originally created, so your driver needs to stretch/shrink it to fit the new window size as part of the buffer swap operation.

You need to destroy and recreate your context for this to work properly.

Thanks for the reply!

I tried that and, unfortunately, it didn’t work…
I was about to write down here the code i used to destroy and recreate the context for you to check it, but then i noticed that it’s not a matter of size, or even height, it’s just a matter of the window lower border being behind the task bar…let me explain: even if i do not resize the window, and i simply take it as it is and drag it until the lower border goes under the task bar…the FPS count drop still occurs, and in the same way! I could not believe it when i saw it and i know it sounds odd (and surely it doesn’t help the label “newbie” under my account name, which by the way i really am) but…that’s just what i’m facing :smiley:

Thanks for the help, i appreciate it!

ps: if i drag the window outside the screen in any other direction (left or right) the FPS count remains constant, at a rate of 500+

ps2: i know for sure it’s not just some monitor sync stuff because if i introduce some little delay into the program loop with Sleep(), the FPS count drops accordingly, being 55-60 instead of 70 etc

Interesting.

Just checking a few things first then.

Have you got CS_HREDRAW | CS_VREDRAW in your window class style?

CS_OWNDC shouldn’t matter any more, but it’s no harm to add it anyway in case you’ve got a temperamental driver that expects it.

Double-check that you’ve got WS_CLIPCHILDREN | WS_CLIPSIBLINGS in the window style used for your CreateWindow(Ex).

You should be handling WM_ERASEBKGND in your program; no need for any special handling, just don’t let it go through DefWindowProc. Note that this message is unusual in that you return non-zero if you handle it yourself.

Also double-check that you’re not drawing from WM_PAINT.

And finally check for PFD_SUPPORT_COMPOSITION when creating your pixel format.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.