How slow is window.draw() ?

[Dalini]

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:

• Without displaying a sprite: 350 FPS
• When displaying a sprite: 230 FPS

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 ?

[eXpl0it3r]

"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?

[Dalini]

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.

[wintertime]

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.

[Jebbs]

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.

[Dalini]

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.

[FRex]

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.

[eXpl0it3r]

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.