Article View: rec.games.programmer
Article #1568Re: Triple Buffering: NOT!
From: Louis Giglio
Date: Thu, 24 Dec 1992 20:22
Date: Thu, 24 Dec 1992 20:22
51 lines
2837 bytes
2837 bytes
In article <1992Dec24.185505.27786@mprgate.mpr.ca>,
vanderby@mprgate.mpr.ca (David Vanderbyl) writes:
|> eker@loria.fr (Steven Eker) writes:
|> >If your frame redraw code takes longer than one video frame, one way
of speeding
|> >things up is to use triple buffering rather than double buffering.
|> [explanation deleted]
|>
|> Triple buffering is completely useless. (Almost) Here's why.
|>
|> Let's say your screen redraw takes 0.9 of the frame rate time.
|> No problem, right? You simply draw each frame and wait for
|> the vertical retrace.
|>
|> Now let's say your screen redraw takes 1.1 of the frame rate time.
|> If the frame rate is 1/30 second per frame then your redraw takes
|> 1.1/30 of a second. So in 1 second you need to draw 30 frames for
|> a total of 1.1/30 * 30 = 1.1 seconds. It doesn't matter how many
|> buffers you use, you can't do 1.1 seconds worth of drawing in 1
|> second.
|>
|> To the person who posted their triple buffering idea:
|> Please state that you idea is just that, an idea. (and in this
|> case not a very good one.) It will save a lot of people from
|> being misled.
If you sit down with a piece of paper and pencil I think you will see
that you are actually wrong. Look at it this way: with your double
buffering scheme the CPU sits around and does *nothing* while it waits
for the next frame. With triple buffering the CPU starts drawing the
next
frame, so it effectively has a head start.
Get some paper and start a sequence like this:
display (double buffer) (triple buffer)
.03333 sec draw frame 0.03666 sec draw 0.03666 sec
.03333 sec DO NOTHING 0.03 sec start next frame 0.03 sec
FLIP
.03333 sec draw frame 0.03666 sec finish frame 0.00666 sec
{still drawing/waiting} {can flip next page here}
.03333 sec DO NOTHING 0.03 sec start next frame 0.06 sec
{now flip}
I know this "chart" is a confusing mess, but if you work it out
yourself,
you'll see the point.
The triple buffered display gets slightly ahead of the double buffered
display, yielding a higher frame rate.
Technical Details
Message-ID:
<1992Dec24.152230@betsy.gsfc.nasa.gov>Path:
arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!agate!ames!nsisrv!betsy.gsfc.nasa.gov!giglioReferences:
<1992Dec21.171731.26731@midway.uchicago.edu> <1992Dec22.202057.18233@blkbox> <709@muller.loria.fr> <1992Dec24.185505.27786@mprgate.mpr.ca>Show Full Headers
Complete Article Headers
Newsgroups: rec.games.programmer Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!agate!ames!nsisrv!betsy.gsfc.nasa.gov!giglio From: giglio@betsy.gsfc.nasa.gov (Louis Giglio) Subject: Re: Triple Buffering: NOT! Message-ID: <1992Dec24.152230@betsy.gsfc.nasa.gov> Keywords: buffering Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet) Nntp-Posting-Host: betsy.gsfc.nasa.gov Reply-To: giglio@betsy.gsfc.nasa.gov (Louis Giglio) Organization: NASA/GSFC References: <1992Dec21.171731.26731@midway.uchicago.edu> <1992Dec22.202057.18233@blkbox> <709@muller.loria.fr> <1992Dec24.185505.27786@mprgate.mpr.ca> Date: Thu, 24 Dec 1992 20:22:30 GMT Lines: 53