Double Buffering

[jerryd]

SFML forum,

 I have converted to 2.0,  not too bad.

 I have a question about the Screen.display() command, Screen being
 obtained by RenderWindow.

 With double buffering I call one buffer the off-screen buffer
 and the other one the on-screen buffer.

 It looks like when you do a Screen.display() these 2 buffers
 are flipped.  Is that correct?

 Other graphics libraries I have used just copy the off-screen
 buffer into the on-screen buffer and retain what was in the
 off-screen buffer.

 Is there a way to do this with SFML.

Jerryd

[OniLinkPlus]

Why would you want to do this? There is no advantage to it, and it is a LOT slower because it has to copy everything.

[jerryd]

OniLinkPlus,

 Flipping has to copy to and from both bitmaps,  seems like that
 would take longer than just a simple one way copy.

 If it flips and there was a sprite move I have to completely
 rewrite the off-screen buffer.

 With a simple copy I only need to move the sprite,  the pixels
 behind the old sprite position are automatically restored, and
 then just copy to the on-screen buffer.

Jerryd

[Jebbs]

I just did a simple test and it appears to be a swap for me. Is there anything specific you are trying to do though? There shouldn't be any big deal with doing a clear, draw, display phase every frame. And a simple look at wikipedia shows that swapping the two buffers is actually faster than the copy since both buffers are already in video memory.

Why would you want to do this? There is no advantage to it, and it is a LOT slower because it has to copy everything.

As far as I know, double buffering is something that happens by default. SFML should be drawing to a buffer, which get's displayed. While the "front" buffer is on the monitor, we would be drawing to a "back" buffer which will be switched with and becomes the front buffer during your monitor's refresh. And it happens again and again.

[OniLinkPlus]

OniLinkPlus,

 Flipping has to copy to and from both bitmaps,  seems like that
 would take longer than just a simple one way copy.

 If it flips and there was a sprite move I have to completely
 rewrite the off-screen buffer.

 With a simple copy I only need to move the sprite,  the pixels
 behind the old sprite position are automatically restored, and
 then just copy to the on-screen buffer.

Jerryd

Unless I'm misunderstanding, you seem to think that double buffering copies the contents of the buffers to each other? This is completely false. All that happens is that a pointer is swapped. One frame, the graphics card reads from one buffer. The next frame, it reads from the other. There is no copying involved.

If a sprite "just moves," you have to completely redraw the buffer anyways, or you'll have a "ghosting" effect where the sprite appears in both its old position and its new position. You could redraw both where the sprite was and where the sprite is now to be rid of the ghosting, but determining what sprites will have to be redrawn and then redrawing them only in those spots would be needlessly complex and time consuming for the graphics cards, especially if you have multiple sprites moving, which you almost definitely will. In fact, it's far more efficient in general to just redraw everything each frame.

[OniLinkPlus]

Why would you want to do this? There is no advantage to it, and it is a LOT slower because it has to copy everything.

As far as I know, double buffering is something that happens by default. SFML should be drawing to a buffer, which get's displayed. While the "front" buffer is on the monitor, we would be drawing to a "back" buffer which will be switched with and becomes the front buffer during your monitor's refresh. And it happens again and again.

Um, yes, that's why I think he shouldn't be bothering with this. Double buffering is already implemented by default, and is far better than what he wants to do.

[Jebbs]

Why would you want to do this? There is no advantage to it, and it is a LOT slower because it has to copy everything.

As far as I know, double buffering is something that happens by default. SFML should be drawing to a buffer, which get's displayed. While the "front" buffer is on the monitor, we would be drawing to a "back" buffer which will be switched with and becomes the front buffer during your monitor's refresh. And it happens again and again.

Um, yes, that's why I think he shouldn't be bothering with this. Double buffering is already implemented by default, and is far better than what he wants to do.

I think he was just trying to change the way the double buffering is actually being implemented since he thought the copy implementation was faster than the swap.

On a side note, my apologies for explaining what double buffering was. I just kind of wrote it before I realized who I was explaining it to. I'm sure you already knew before hand.

[jerryd]

SFML forum,

 My point is that I work in the off-screen or back buffer as it's
 often called and then call Screen.display().  This may flip or
 just change the pointers but in either case the back buffer now
 has data that's 1 frame behind.  Now I have no choice but to
 redraw the entire back buffer which takes time.  If the back
 buffer was left in tact I could just reposition whatever moved
 and and do the one way copy.

 But if clearing and completely redrawing the entire back buffer
 is faster than coping one buffer to another I can understand
 why it's done that way.

 Does anyone have anyone know these execution times.

Jerryd

[Jebbs]

This may flip or just change the pointers but in either case the back buffer now has data that's 1 frame behind.

Not really. People are reacting to the frame that is currently being displayed, right? So frame is displayed, you receive input from the player, and then you redraw the scene based on what has changed. If you are drawing at 60 FPS an entire loop of getting input, updating your systems, and redrawing happens in the span of ~16.6 milliseconds. The player isn't going to experience any kind of delay from something like this.

If the back buffer was left in tact I could just reposition whatever moved and and do the one way copy.

Even in this case you would still have to clear the contents of the back buffer in order to redraw. Unless you can magically move pixels like how you are describing.

Does anyone have anyone know these execution times.

Fast. You can always time it if you are curious, but the clear and draw methods themselves should be almost negligible. It's all the drawing that takes up time.

[jerryd]

SFML forum,

 Some graphics libraries will automatically save the pixels behind a
 sprite before it's moved and automatically replace those pixels after
 the sprite is moved.

 I will do some timing but I'm almost convinced the SFML method is as
 fast as anything else.

 Thanks for all the replies.

Jerryd

[eXpl0it3r]

Some graphics libraries will automatically save the pixels behind a
 sprite before it's moved and automatically replace those pixels after
 the sprite is moved.

This is an outdated way of handling graphics. SFML is designed to have functions for drawing in real time. And thus you'll always have to call clear() before drawing another frame.
If you have something that gets built up over time, regardless of the frames, you can use sf::RenderTexture, which is basically another off-screen buffer. But you should not try to replicate the functionality described above with SFML!

I will do some timing but I'm almost convinced the SFML method is as
 fast as anything else.

Yes it's fast enough.

[OniLinkPlus]

SFML forum,

 Some graphics libraries will automatically save the pixels behind a
 sprite before it's moved and automatically replace those pixels after
 the sprite is moved.

 I will do some timing but I'm almost convinced the SFML method is as
 fast as anything else.

 Thanks for all the replies.

Jerryd

No, the calculations behind that process are both CPU and GPU intensive, and in general, if you have multiple sprites moving (which you WILL), it is FAR slower than just redrawing everything.

[Nexus]

By the way, please don't break lines manually, it just makes your text harder to read. Thanks

[Laurent]

I thought that I made the tutorial clear enough about this particular point.

This clear/draw/display cycle is the only good way to draw things. Don't try other strategies, such as keeping pixels from the previous frame, "erasing" pixels, or drawing once and calling display multiple times. You'll get strange results due to double-buffering.
Modern graphics chipsets and APIs are really made for repeated clear/draw/display cycles where everything is completely refreshed at each iteration of the main loop. Don't be scared to draw 1000 sprites 60 times per second, you're far below the millions of triangles that your computer can handle.

(yes, it's written in red in the tutorial)