Optimizing CPU usuage

[thatoneguy]

Alright so I had a thread earlier about calculating FPS after window.display() is called, but my while loop doesn't always call window.display() only when there is user input. CPU usage hits a peak of 20% for the program because of the while loop. I implemented the following to limit it:

void Root::CheckElapsedTime(sf::Clock &clock) {
    if (elapsedTime >= 1.0f / float(framesPerSecond)) {
        std::cout << "While Loop: " << 1.0f / elapsedTime << std::endl;
        elapsedTime = 0;
        return;
    }
    sf::sleep(sf::seconds(1.0f / float(framesPerSecond) - elapsedTime));
    elapsedTime += clock.restart().asSeconds();
    CheckElapsedTime(clock);
}

I have the frame-limit set to 30, and FPS is just shy of 30 which is good. CPU usage drops to a peak of 3%. Is this implementation correct, and is there a better way to optimize it?

[MadMartin]

but my while loop doesn't always call window.display() only when there is user input.

Why do you do this? Look at the big red box on this page: http://sfml-dev.org/tutorials/2.1/graphics-draw.php
It is absolutely correct to to a clear->draw->display every frame. Don't mess with this concepts if you are using SFML (and OpenGL and DirectX aka. all modern acclerated graphics APIs/Libs).


Why do you want to reduce CPU usage? Is your program designed to run as a background process? Then I wonder why you use SFML.
If you program is the "main" running program, like it is normal for a (fullscreen) game, you shouldn't limit your CPU usage without any reason!

[Lo-X]

As said above, if you do not display() your game will look (to the player) like frozen while he doesn't move the mouse or press some keys.

You shouldn't be looking at performances yet. First, get something playable. If you *really* have performances issues once done, then do scan/analyze/make changes.

[thatoneguy]

I'm also running this on an older computer and that's the reason for wanting to reduce the CPU usage. The program is more of a form application, though I remember reading SFML is more for real time applications.

Regarding the clear->draw->display I may have been unclear.  To clarify my program will run updates every 1/30th of a second but not draw every iteration, and it calls clear()->draw()->display() when there is something that needs to be drawn.

Isn't it fine to keep the old frame shown as long as I'm not using any old pixels in the next frame? When I do need to display something I'll go through clear->draw->display, not using any pixels from the previous frame, but I'm not going through clear->draw->display every frame since there isn't anything new to be drawn. I'm not really doing anything against what the red box states other than being scared to draw frames several times a second, am I?

[The Terminator]

Recycling frames is never a good idea. The system your seeking will be a lot more work for little extra reward. Your code will be far more error prone and hard to maintain. Furthermore, for your code, 20% CPU usage isn't really that much. You say that you're on an older computer, but you can safely bet people that play your game will have newer GPUs and CPUs which will handle it a lot better. Don't fix what isn't broken.

[Nexus]

Isn't it fine to keep the old frame shown as long as I'm not using any old pixels in the next frame?

No. When you don't call display() often enough, the application will be unresponsive. SFML is really conceived for real-time rendering, which assumes you're calling those functions in a regular fashion.

What you can do is have different logic and graphic update rates; but you should still update graphics regularly. But don't make your life complicated if there's no need to.