SFML community forums

Help => General => Topic started by: Dalini on December 19, 2013, 05:35:28 pm

Title: How slow is window.draw() ?
Post by: Dalini on December 19, 2013, 05:35:28 pm
Hi there,

I'm running a very basic SFML app, with two cases. One where I display a sprite, one where I do not.
Here is the FPS between thoses cases:


Here are the code sample:

sf::RectangleShape background_;
background_.setSize(sf::Vector2f(1900, 1000));
background_.setFillColor(sf::Color(235, 235, 235));
background_.setOutlineColor(sf::Color::Black);
background_.setOutlineThickness(1);
background_.setPosition(20, 20);

sf::RenderWindow window(sf::VideoMode(1920, 1080, 32), "Title");

while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
                // Close window : exit
                if (event.type == sf::Event::Closed || sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)) {
                        window.close();
                }
        }

        window.clear(sf::Color(150, 150, 150));

    // Upon uncommenting this line, I lose about 120 FPS
        //window.draw(background_);

        window.display();
}
 

Of course getting from 350 FPS to 230 is acceptable, it still is a high value, but the problem is that when I try to display several hundred of sprites (just sf::Shape, nothing fancy), I get below 25 FPS.

Any idea about what I am doing wrong ?
Title: AW: How slow is window.draw() ?
Post by: eXpl0it3r on December 19, 2013, 05:55:36 pm
"several hundreds" is how many exactly?

FPS is non-linear, thus it's hard to make a judgment based on some drop in FPS, but SFML should be able to handle a few thousand sprites/shapes on a more or less modern GPU.

Is your GPU driver uptodate? What GPU do you have?
Title: Re: AW: How slow is window.draw() ?
Post by: Dalini on December 19, 2013, 06:04:33 pm
Quote from: eXpl0it3r on December 19, 2013, 05:55:36 pm
FPS is non-linear, thus it's hard to make a judgment based on some drop in FPS, but SFML should be able to handle a few thousand sprites/shapes on a more or less modern GPU.

That was exactly my thought.
I'm talking about something like 600 sprites. But the FPS drops doesn't seem to be related to the number of sprites, but to their size.

I just tried something else:

sf::RectangleShape background_;
background_.setSize(sf::Vector2f(1900, 1000));
background_.setFillColor(sf::Color(235, 235, 235));
background_.setOutlineColor(sf::Color::Black);
background_.setOutlineThickness(1);
background_.setPosition(20, 20);

sf::RenderWindow window(sf::VideoMode(1920, 1080, 32), "Title");

while (window.isOpen()) {
    sf::Event event;
    while (window.pollEvent(event)) {
        // Close window : exit
        if (event.type == sf::Event::Closed || sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)) {
            window.close();
        }
    }

    window.clear(sf::Color(150, 150, 150));

    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);
    window.draw(background_);

    window.display();
}
 

That's only 10 sprites, shouldn't be a problem right? and yet the FPS is down to 55 with that code (the FPS is given by FRAPS by the way).

The GPU is Intel(R) HD Graphics 4000.

Title: Re: How slow is window.draw() ?
Post by: wintertime on December 19, 2013, 07:19:17 pm
Those artificial "benchmarks" wont give you any useful info. There is some significant per frame overhead when you only draw a few things, time taken scales nonlinearly as there is more or less parallelism inside the gpu, you doing several useless fullscreen rectangles produces more overdraw/fragment calculations than any real application.
Just program your game and wait with optimizing until it is really needed.
Title: Re: How slow is window.draw() ?
Post by: Jebbs on December 19, 2013, 07:51:29 pm
I very much agree with wintertime. Just make your game. If performance becomes an issue where the game is starting to become unplayable, then optimize.

I'd like to add that calculating the time it takes to draw a frame is going to give you significantly more meaningful data than looking at FPS, especially since FPS can fluctuate quite a lot with very miniscule changes to your draw time.

Also, if you are going to look at FPS at all, don't use fraps if you want really accurate numbers. It adds some overhead and will make things look like they aren't running as fast.
Title: Re: How slow is window.draw() ?
Post by: Dalini on December 19, 2013, 08:19:18 pm
Quote from: wintertime on December 19, 2013, 07:19:17 pm
Just program your game and wait with optimizing until it is really needed.

I totally agree and that's what I was doing. It worked fine on a small map, and then came the big one, and I had 20 FPS for only 500-600 sprites displayed. I tried to profile it, it appeared that the window.draw() where taking away most of the FPS.

I checked my code, and I'm not doing something stupid like creating the sprites every update.

I'm out of ideas, and it seemed to me that something as simple as that shouldn't be so slow.
This is why I asked on this forum.
Title: Re: How slow is window.draw() ?
Post by: FRex on December 19, 2013, 09:07:07 pm
You need to reduce amount of draw calls by using vertex arrays(look for info in tutorial on vertex arrays and in tons of posts and threads on the forum).
There is also tile maps specific method for drawing using a shader which Dbug came up with and I reimplemented/investigated on my own based on his proof of concept.
Title: Re: How slow is window.draw() ?
Post by: eXpl0it3r on December 20, 2013, 01:58:31 am
To answer the subject line, yes the draw function can indeed be slow, but in most cases GPU's are good enough to handle up to a few thousand draw calls per frame. If those draw calls start to get noticeable, then it's time to get the bigger guns out, as FRex said, using vertex arrays. With them you can lower the draw calls to a few.

If you haven't checked Intel's website for driver updates, you should do that now!
Overall one can say, Intel cards got better over the past few years, but they are still a pain to work with.