🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: rec.games.programmer
Article #1568

Re: Triple Buffering: NOT!

#1568
From: Louis Giglio
Date: Thu, 24 Dec 1992 20:22
51 lines
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!giglio
References: <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