Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

John Carmack has a tweet:

"Triple buffering adds latency and jitter; it should be avoided. The Answer is non-isochronous display updates."

Can anyone explain what he meant by adds latency and jitter?

share|improve this question
add comment

2 Answers 2

I have an idea of where the jittering comes from with vSync and triple buffering. The easiest way to show this is visually.

The first example would be 30fps with a 60hz refresh rate vSynced with Double buffering. The pipes are new frames and periods are duplicated frames.

|.|.|.|.|.|.|.|.|.

This gives an even ~33ms between each new frame, which makes it appear smooth (for 30 fps anyway). You can see how fitting 60fps into the same situation fits perfectly into the timing interval, allowing for a new frame every refresh.

Now, lets see how it would look running 45fps at a 60hz refresh rate vSynced with Triple Buffering:

|||.|||.|||.|||.|||.

You can see here that there is an uneven interval between frames. In this case, the frame times are 16,16,16,33,16,16,16,33. Since the monitor only updates once every ~16ms, if a new frame isn't ready for a particular update, it still has to wait a whole additional ~16ms, even if its ready 1-2ms after the previous update.

However, I think the whole TB situation is still debateable and depends on the situation. Personally, I'd rather see 55fps with no tearing with occasional dropped frames than to go all the way down to 30fps to get even frame timing.

As a side note, this is a good example of how a 120hz monitor can increase smoothness of a game running at ~45fps since there is a higher frequency of times that a new frame can be displayed to the screen.

share|improve this answer
add comment

It adds latency because you've got 3 buffers involved instead of 2, so it takes one more frame for your rendered image to get to the screen.

I have no idea what kind of "jitter" Carmack is talking about here, though.

EDIT

Maybe, just maybe, this could make sense in a highly variable framerate context: frames rendered with a given delta-time but displayed later with a different delta, resulting in a visible jitter?

share|improve this answer
    
When John Carmack refers to triple buffering does that mean when all three buffers have images in them the earliest backbuffer is replaced with the new image or does that mean that mean rendering of the new image is blocked until one of the backbuffers is available? –  user782220 Jul 5 '12 at 20:21
    
Buffer #1 is being rendered into. #2 is being displayed. #3 is waiting for a good time to replace #2 on the display. The additional latency allows rendering to continue instead of pausing for the swap like a double buffered setup. If you're done rendering before the swap then yes, you'd get some jerking because of the pauses happening two frames behind the current real time. Summary: you're using a current time to smooth out a historical render, which can vary and make for small twitches. –  Patrick Hughes Jul 6 '12 at 4:05
    
@PatrickHughes: Your explanation of why there is jerking doesn't make sense. –  user782220 Jul 6 '12 at 7:48
    
If you measure your interval by the previous flip, which was based on rendering from two frames ago, and then use that interval to calculate data in the current frame you're always going to be lagging the real interval by one frame. If your frames vary in time by any amount this will cause a following behavior where the game calculations don't match what will be displayed from those calculations.\ –  Patrick Hughes Jul 6 '12 at 17:53
    
Why measure your interval from the previous flip instead of the previous frame? Every new frame usually uses the timing from the previous frame for any time-based calculations like acceleration, etc., and it shouldn't matter, whether that frame was already displayed on screen or not. –  Mario Oct 28 '12 at 23:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.