SFML RenderTexture slow performance

Started by
2 comments, last by AngryPlatypus 11 years ago
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?
Advertisement
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.
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

Ah, found it, thank you

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.

This topic is closed to new replies.

Advertisement