why triple buffering is theoretically better than double buffering
GNL
spent to much on a reply on triple-buffering. so by just posting it as a new
msg,
i may get more readers so the time spent becomes more valuable...
triple buffering can improve on a steadier and give a higher framerate.
haven't got
my directx book at hand now, so i'll try to explain by head:
The buffer in buffering is a bitmap the size of your screen res. . The
number before that is is the number of bitmaps you reserve for that. the
bitmaps are linked in a circular chain, which is rotated every frame. If you
have more than a single buffer, there's always one buffer showing on the
screen (front buffer). in the case of a double buffer, the "back" buffer is
used for drawing onto. After it's finished drawing, the front and back are
flipped. If vsync is enabled, this flipping occurs exactly at the moment the
electron beam of the monitor jumps back from bottom right to top left. This
way, the visual effect known as "tearing" won't occur.
Example of tearing: when you animate a circle which moves over the
screen from left to right and you flip the buffers in the middle of a
screen-drawing, the circle will be split in half, the bottom half part being
located more to the right, since this is a part of the animation where
circle has moved to the left somewhat more than the frame before (top half
of the circle).
However, this double buffering with vsync can cause the fps being less than
optimal. Example:
monitor at 80Hz
app capable of calculating 60 fps
t = time since t=0
aX = app-frame
mX = mon-frame
t = 0 : start drawing a1
t = 1/80 : vsync, m1 showed black frame
t = 1/60 : a1 ready, app waits for vsync
t = 1/40 : vsync, m2 shows black frame, so flip to a1, start drawing a2
t = 1/27 : vsync, m3 showed a1, a2 not ready yet, so show a1 again
t = 1/24 : a2 ready (1/40 + 1/60), app waits for vsync
t = 1/20 : vsync, m4 showed a1, flip to a2, start drawing a3
t = 1/16: vsync, m5 showed a2, a3 not ready yet, so show a2 again
t = 1/15 : a3 ready (1/20 + 1/60), app waits for vsync
t = 1/13 : vsync, m6 showed a2, flip to a3, start drawing a4
t = 1/11.4: vsync, m7 showed a3, a4 not ready yet, so show a3 again
t = 1/10.9 : a4 ready
t = 1/10: vsync, m8 showed a3, flip to a4, start drawing a5
t = 1/8.8: vsync, m9 showed a4, a5 not ready yet, so show a4 again
t = 1/8.6: a5 ready
t = 1/8: vsync, m10 showed a4, flip to a5, start drawing a6
t = 1/7.3: vsync, m11 showed a5, a6 not ready yet, so show a5 again
t = 1/7.1: a6 ready
t = 1/6.7: vsync, m12 showed a5, flip to a6, start drawing a7
t = 1/6.2: vsync
t = 1/6: a7 ready
ok you get the idea...
anyway when you calculate the effective framerate out of 7 frames in 1/6 of
a second, you get 42 fps instead of 60.
ok now with triple buffering. the cool thing about triple buffering is that
the app can immediately continue to draw onto the next bitmap in the chain
after the current frame is finished and there's always something ready to
flip:
monitor at 80Hz
app capable of calculating 60 fps
t = time since t=0
aX = app-frame
mX = mon-frame
bX = buffer+number
t = 0 : start drawing a1 on b1
t = 1/80 : vsync, m1 showed black b3
t = 1/60 : a1 ready, start drawing a2 on b2
t = 1/40: vsync, m2 showed black b3, flip to a1-b1
t = 1/30: a2 ready, start drawing a3 on b3
t = 1/27: vsync, m3 showed a1-b1, flip to a2-b2
t = 1/20: vsync, m4 showed a2-b2, a3 ready, flip to a3-b3, start drawing a4
on b1
the circle is round very quickly in this case. 3 frames in 1/20 sec = 60
fps. (this will loop)
When vsync is disabled, double-buffering is enough, coz the app then won't
wait for the vsync anyway.
In practise there won't be much of a difference between double and triple
buffering, esp. when the number of time spent on other things than 3d
drawing (ai, physics etc.) is particularly high (as in games).
GNL
p.s i hope it makes sense, correct me if i'm wrong with this...
Rune Dahl Jørgensen
I knew nothing about it.
R*
GNL <d...@ddd.nl> skrev i en nyhedsmeddelelse:8dq84d$if6$1...@tesla.a2000.nl...