Low framerate for empty rendering?

[rofer]

Hi, I've recently noticed that I don't get much more than 1700fps when rendering to a window even if the rendering really does nothing. Here is the test program I've been using:

#include <GL/glew.h>
#include <SFML/System/Clock.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <cstdio>

int main() {
  sf::ContextSettings cs(0, 0, 0, 3, 2); /* Request OpenGL 3.2 */
  sf::Window *mainWindow = new sf::Window(sf::VideoMode(1200, 600, 32),
    "SFML Test", sf::Style::Default, cs);
  mainWindow->setVerticalSyncEnabled(false);
  sf::Clock calcClock;
  int frames = 0;
  while(mainWindow->isOpen()) {
    glClear( GL_COLOR_BUFFER_BIT );
    mainWindow->display();
    frames++;
    if(frames >= 1000) {
      int calcTicks = calcClock.getElapsedTime().asMilliseconds();
      printf("FPS: %f Frames: %i Ticks: %i\n", frames/(calcTicks / 1000.0f),
          frames, calcTicks);
      frames = 0;
      calcClock.restart();
    }
  }
  return 0;
}

Any idea why I'm being limited to this? I can get things a bit faster if I fullscreen it, but I'm still not getting anything close to 10,000fps like I would expect when I'm doing so little. I'm not sure if this is because of overhead in SFML or something else. Anyone care to enlighten me?

[The Hatchet]

1700?  And you think its slow?  thats like 3x the most I've ever seen from a base program that does nothing from the machines I've worked on.  My projects usually start out around 500-600 fps. 

1700 is hella fast, you should only start worrying once it dips below 60.

[Laurent]

And why would you get 10000 FPS instead of 1700? Both numbers are huge, and don't reflect the performances that you'll get when you'll draw things.

In can be anything: event processing, the display() function, etc. The overhead of these functions is usually negligible, but if that's all you have in your game loop, it becomes significant. Seriously, write your app, don't stop on such things.

[OniLinkPlus]

1700 fps? That barely over half a millisecond per frame. If you're expecting to get faster than that on any computer other than a ridiculously high end computer or a supercomputer, you are, quite frankly, insane. ESPECIALLY when you're writing to the console every thousand frames.

[rofer]

I thought I recalled seeing glxgears run at 20,000+ fps on one of my machines before so I just assumed that's what a really simple OpenGL application should be able to do (try this out more recently is yielding similar numbers as to what my empty application is getting). Having written some CUDA programs recently I've seen how much can be done in half a millisecond and was a little surprised I wasn't getting more.

Looks like my assumption that I could do better was flawed, thanks for the insight. This certainly hasn't stopped me from developing my application, just wanted to be sure I understood the performance here.

[victorlevasseur]

You don't have an event loop in your test app : this loop is needed (event if you don't use events). It may reduce the app's performances.

[Grimshaw]

We need Myth busters to do something about the FPS myth xD

[rofer]

You don't have an event loop in your test app : this loop is needed (event if you don't use events). It may reduce the app's performances.

I'm pretty convinced now that I'm getting nearly the maximum performance I can, I'm curious about what you've said though. How can not having an event loop slow my performance down?

[Ixrec]

Having an event loop allows the window to process its own internal events in the background, even if your code doesn't do anything with any of the SFML-defined events.  Windows kind of assume they'll get to do this processing constantly, so I wouldn't be surprised if things ran slower when they don't get to, just because that's not what the system or the window is expecting.  I don't know for sure if that happens though.

[eXpl0it3r]

It won't be noticable slower, but it will steadily use more memory, since every event gets placed into a queue and if they don't get dispatched, they'll just stay there and increase the memory usage by a bit.
Thus if you use SFML's window module you should always dispatch events.

[Antidote]

The human eye can only detect movement up to about 100 Hz, some really lucky (or unlucky if you view it that way) eyes can detect up to 120 Hz. Having a framerate of over 1k is ridiculous because no one will ever see them, MOST console games run between 30 to 60 FPS, and 60 FPS is 120Hz so what are you losing out on?

EDIT:
As an example, one of my personal favorite games Metroid Prime has it's FPS capped at 30 internally, you CAN edit the binary to have it higher, but since movement is based on delta's (something I didn't think Retro was too worried about) you don't really notice it.

[eXpl0it3r]

The human eye can only detect movement up to about 100 Hz, some really lucky (or unlucky if you view it that way) eyes can detect up to 120 Hz. Having a framerate of over 1k is ridiculous because no one will ever see them.

Not quite. Our eye is not really the "blocking" factor here, but it's our brain for most parts. We just don't "render" the differences, but especially for competitive first person shooters a high framerate will make a difference to the player, because information can also get processed without yourself actually noticing it, given that you have a 120Hz monitor.
But you're right 1000 FPS is useless.

MOST console games run between 30 to 60 FPS, and 60 FPS is 120Hz so what are you losing out on?

Wrong. 60 FPS = 60 Hz and 120 FPS = 120 Hz
Hertz is defined as x periods per second and since we're talking about framerate, it's x frames per second.

30 FPS for good enough for most of the games. If you have a lot of camera movement you might be noticing it though.
60 FPS is enough for any game.
120 FPS will mostly be wasting resources, because most of the screen on the market have a refresh rate of 60 Hz.