🚀 go-pugleaf

giglio@betsy.gsfc.nasa.gov (Louis Giglio) writes:

>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.
>|> 
[explanation deleted]
>|> 
[unwarrented preaching deleted]


>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.

[table-deleted]

>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.

I do see the point.  But what are you going to do with about 25 frames
when the frame rate is 30?  I don't think showing 25 frames with some
repeats will be much better animation than showing 15 frames with all
repeats.

Of course, we are assuming that the redraw rate is just longer than the
frame rate.  Of course if the redraw rate was a lot longer then triple
buffering could improve things. An example would be if we could increase
from 4 to 5 redraws per second.