Originally posted by bgl:
Yes. And, for those who haven’t thought it
through: you have to wait one frame to see
your results at 50 fps (double-buffered),
which means 20 ms. You have to wait TWO
frames to see your result at 90 fps (triple-
buffered), which means 22 ms.
Wrong. If running at 100hz monitor refresh rate, starting on a 0ms based timeline:
Assuming 11ms render time with double buffering:
*frame 0 starts at 0ms, completes at 11ms and is displayed at 20ms
*frame 1 starts at 20ms, completes at 31ms and is displayed at 40ms
*frame 2 starts at 40ms, completes at 51ms and is displayed at 60ms
Assuming 11ms render time with triple buffering:
*frame 0 starts at 0ms, completes at 11ms and is displayed at 20ms
*frame 1 starts at 11ms, completes at 22ms and is displayed at 30ms
*frame 2 starts at 22ms, completes at 33ms and is displayed at 40ms
*frame 3 starts at 33ms, completes at 44ms and is displayed at 50ms
*frame 4 starts at 44ms, completes at 55ms and is displayed at 60ms
remembering that any input before a frame starts is viewed when that frame is displayed:
*input at time 0ms is displayed at 20ms with double buffering and at 20ms with triple buffering
*input at time 10ms is displayed at 40ms with double buffering and at 30ms with triple buffering
*input at time 19ms is displayed at 40ms with double buffering and at 40ms with triple buffering
*input at time 21ms is displayed at 60ms with double buffering and at 40ms with triple buffering
clearly in this case latency is better with triple buffering. I did pick one of the better case scenarios for my example, but in summary, any time that your render code runs slower than the refresh rate triple buffering will help, and the smaller the ratio of “(render time) : (render time + flip delay)” the more triple buffering helps.
Of course, in the real world, you typically
don’t have this “near miss”; the average
frame time might be between one and two
frames (thus 15 ms in your example) which
results in still 50 fps/20ms for the double
buffer case, but 67 fps/30ms for the triple
buffer case.
Wrong. With triple buffering, you typically dont buffer up an extra frame unless your rendering code is rendering faster than the refresh rate. The third buffer just gives you a place to start working on frame X+1 while you are waiting for the last flip (frame X) to complete. By the time you finish frame X+1, frame X has completed, and your frame is ready to be displayed on the VERY NEXT vsynch. Since you dont have to wait any additional vsynchs, but you started on the frame earlier than you would have with double buffering, the result is that your frame gets displayed at the same time or earlier than it would have with double buffer.
Like I said, a latency of 1 frame IS an issue if you are rendering faster than the refresh rate. Now this is a debateable issue, but personally I feel that if your code is already rendering at 60hz or higher, its not that big of a deal and I can stand a single frame of latency. However, with a lot of cutting edge games you are lucky to be able to run at refresh rate, and triple buffering is often a win (if you can afford the extra video memory).
To examine your 15ms example:
Assuming 15ms render time with double buffering:
*frame 0 starts at 0ms, completes at 15ms and is displayed at 20ms
*frame 1 starts at 20ms, completes at 35ms and is displayed at 40ms
*frame 2 starts at 40ms, completes at 55ms and is displayed at 60ms
Assuming 15ms render time with triple buffering:
*frame 0 starts at 0ms, completes at 15ms and is displayed at 20ms
*frame 1 starts at 15ms, completes at 30ms and is displayed at 30ms
*frame 2 starts at 30ms, completes at 45ms and is displayed at 50ms
*frame 3 starts at 45ms, completes at 60ms and is displayed at 60ms
remembering that any input before a frame starts is viewed when that frame is displayed:
*input at time 0ms is displayed at 20ms with double buffering and at 20ms with triple buffering
*input at time 14ms is displayed at 40ms with double buffering and at 30ms with triple buffering
*input at time 16ms is displayed at 40ms with double buffering and at 50ms with triple buffering
*input at time 21ms is displayed at 60ms with double buffering and at 50ms with triple buffering
while in some cases, the latency for individual inputs can be higher with triple buffering, the average latency is lower.
Consider yourself somewhat “smacked down”
[This message has been edited by LordKronos (edited 01-05-2001).]