Sign in to follow this  
Dennis Majvall

SFML RenderTexture slow performance

Recommended Posts

Dennis Majvall    101
Hey guys, I just started with the C++ library: SFML and while making my game-loop I noticed something disturbing.
 
Relevant part of the Header:
public:
    virtual const sf::Texture Draw();
protected:
    sf::RenderTexture sb;
 
When I try to call the "Draw" method I use this code:
currentRenderScreen->Draw();
 
Which do this:
const sf::Texture RenderScreen::Draw() {
    return sb.getTexture();
}
 
The reason I use a RenderTexture is because I want to draw multiple sprites and images on a texture, and then display the texture as it's whole (I think it's called backbuffer?). And I need to return a "Texture" to be able to draw it in my window.
However it's extremely slow if my "RenderTexture sb" is normally big (800 width 600 height), around 200 milliseconds per call (110 on my friend's computer), if the object sb is 100 px wide and 100 high or smaller it only takes a handful milliseconds to call.
 
I'm pretty sure I'm doing something wrong as using a RenderTexture should be the optimal way to draw stuff in a game?
If it really is this heavy to use, is there any better alternative? Edited by phantom
Reverting this back to the main post as it has an answer.

Share this post


Link to post
Share on other sites
Cornstalks    7030
Look at your Draw method. It's returning a copy of a sf::Texture. Copying textures around is expensive. You should return a const reference (sf::RenderTexture::getTexture() returns a const reference to a texture).

In other words, don't copy the texture around. Use references. And be careful, so that you don't hold a reference to the texture if it gets destroyed.

Edit: on second thought, I'm actually not sure this is a slow operation. I know you said it doesn't affect your performance, but I just wanted to add that after thinking about it (and failing to find specific documentation) I'm not sure if it actually copies the texture (that is, it might just reference the same texture in the video card), and if it does copy the texture, it should be pretty quick (if unnecessary) because it should be a graphics card operation.

Share this post


Link to post
Share on other sites
AngryPlatypus    232

The SFML RenderWindow is already double buffered. The method draw(...) draws to the backbuffer and display() swaps the buffers. So there is no need for a RenderTexture in this case.

 

The texture's copy constructor loads the texture from the gpu in an image and creates a new texture from that image. Both done per pixel and as cpu operation which is definitely slow.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this