2

Let say, we use double buffering. We first write the frame into the back buffer, then it will be swap into the front buffer to be displayed.

There are 2 scenario here, which I assume have the same outcome.

  • Assume we clear the back buffer, we then write a new frame to back buffer. Swap it into the front buffer.

  • Now assume we didn't clear the back buffer, the back buffer will be overwritten with a new frame anyway. Lastly both buffer will be swapped.

Thus, assuming I was right and provided we use double buffering, whether clearing or not clearing buffer, both will then end up with the same display, is that true?

Will there be any possible rendering artifacts, if we didn't clear the buffer?

Kromster
  • 7,181
  • 7
  • 63
  • 111
Yeo
  • 11,416
  • 6
  • 63
  • 90
  • Addition, to the question. The "buffer" specifically refers to the "Color Buffer", since it is in double buffering – Yeo Mar 10 '16 at 14:36

4 Answers4

1

The key of the second approach is in this assumption:

the back buffer will be overwritten with a new frame

I assume we are talking about OpenGL frame buffer which contains Color values, Depth, Stencil and etc. How exactly will they be overwritten in next frame?

Rendering code does constant depth comparisons, so see which objects need to be drawn. With old frame depth data it will be all messed up. Same happens if you render any semi-transparent items, with blending enabled.

Clearing buffer is fastest way to reset everything to ground zero (or any other specific value you need).

There are techniques that rely on buffer not being cleared (considering this is verified to be a costly operation on a platform). For example not having transparent geometry without opaque behind it, and toggling depth-test less/greater in 0-0.5 / 0.5-1.0 ranges to make it always overwrite old frames values.

Kromster
  • 7,181
  • 7
  • 63
  • 111
  • I'm a bit confused now, because as far as I know, double buffering only deals with "Color buffer". Depth & stencil buffer has nothing to do with double buffering. Am I right? If it's true then depth buffer won't really the concern here. – Yeo Mar 10 '16 at 14:31
  • But thanks for raising up the other point where you highlight the **overwritten** part. Isn't it a safe assumption to be made? because the next frame will be written with the same size as the earlier size, hence overwriting all of the existing color buffer. – Yeo Mar 10 '16 at 14:33
  • 1
    @Yeo, no it is not. See for example glxgears(https://upload.wikimedia.org/wikipedia/commons/thumb/6/62/Xf86_glxgears.png/170px-Xf86_glxgears.png). The triangles get rendered each frame, but black background comes from the clear. Without the clear, the new frame is not the entire window, but just the gears that are rendered. – Bas Nieuwenhuizen Mar 10 '16 at 14:49
  • @BasNieuwenhuizen Oh, now i understand where the clear color buffer comes. I thought the world space has always been specific primitive itself, apparently it came after clearing. Unless we made the enclosed world space primitive ourself. – Yeo Mar 10 '16 at 15:32
1

During rendering you depend on the fact that at least the depth buffer is cleared.

When double buffering the value of the back buffer will (possibly) be that what you rendered 2 frames ago.

If the depth buffer is not cleared then that wall you planted your face on will never go away.

The depth buffer can be cleared by for example rendering a full screen quad textured with your skybox while the depth test is disabled.

ratchet freak
  • 47,288
  • 5
  • 68
  • 106
1

Clearing of the buffers is absolutely essential if you like performance on modern hardware. Clearing buffers doesn't necessarily write to memory. It instead does some cache magic such that, whenever the system tries to read from the memory (if it hasn't been written to since it was cleared), it will read the clear color. So it won't even really access that memory.

This is very important for things like the depth buffer. Depth tests/writes are a read/modify/write operation. The first read will essentially be free.

So while you do not technically need to clear the back buffers if you're going to overwrite every pixel, you really should.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
0

After buffer swap the contents of the back buffer are undefined, i.e. they could be anything. Since many OpenGL rendering operations depend on a well known state of the destination frame buffer to work properly (depth testing, stencil testing, blending) the back buffer has to be brought into a well known state before doing anything else.

Hence, unless you take carefull measures to make sure your rendering operations do not depend on destination buffer contents, you'll have to clear the back buffer after a swap before doing anything else.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Could you provide an example of how they are not just "from previous frame", but specifically "undefined" ? – Kromster Mar 10 '16 at 14:01
  • @KromStern: It's not a matter of real world "example". It boils down to that *the OpenGL specification says so*. Anything may happen in practice: You may see the previous frame, see uninitialized memory, solid color, etc. – datenwolf Mar 10 '16 at 14:30
  • @KromStern Modern systems often don't really use double buffering, except maybe for full screen rendering. For windowed rendering, you don't get double buffering per window. Particularly if you picture overlapping windows with shadows, etc, you can imagine that it would be hard to get that working. In reality, you render to a buffer, and that buffer becomes part of window system composition. There can also be things like triple buffering. So assuming that the content from 2 frames ago is in the current buffer will rarely work in reality. – Reto Koradi Mar 11 '16 at 05:12
  • @RetoKoradi aren't double-buffering (DB) implemented on apps render level? I.e. app requests DB from OGL/D3D and renders to back buffer while OS receives front buffer for its compositions? Otherwise we would see rendering being in progress if our single buffer is used for compositions? – Kromster Mar 11 '16 at 05:40
  • @KromStern: No. In OpenGL double buffering details are dealt with internally in the driver, and except for setting a flag and choosing if rendering goes to front or back the application has no control over it. – datenwolf Mar 11 '16 at 08:02