home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / programm / 5185 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.1 KB  |  57 lines
  1. Newsgroups: rec.games.programmer
  2. Path: sparky!uunet!paladin.american.edu!gatech!destroyer!cs.ubc.ca!mprgate.mpr.ca!mprgate.mpr.ca!vanderby
  3. From: vanderby@mprgate.mpr.ca (David Vanderbyl)
  4. Subject: Re: Triple Buffering: NOT!
  5. Message-ID: <1992Dec24.223839.29198@mprgate.mpr.ca>
  6. Keywords: buffering
  7. Sender: news@mprgate.mpr.ca
  8. Reply-To: vanderby@mprgate.mpr.ca (David Vanderbyl)
  9. Organization: MPR Teltech Ltd.
  10. References: <1992Dec21.171731.26731@midway.uchicago.edu> <1992Dec22.202057.18233@blkbox> <709@muller.loria.fr> <1992Dec24.185505.27786@mprgate.mpr.ca> <1992Dec24.152230@betsy.gsfc.nasa.gov>
  11. Date: Thu, 24 Dec 92 22:38:39 GMT
  12. Lines: 43
  13.  
  14. giglio@betsy.gsfc.nasa.gov (Louis Giglio) writes:
  15.  
  16. >In article <1992Dec24.185505.27786@mprgate.mpr.ca>,
  17. >vanderby@mprgate.mpr.ca (David Vanderbyl) writes:
  18. >|> eker@loria.fr (Steven Eker) writes:
  19. >|> >If your frame redraw code takes longer than one video frame, one way
  20. >of speeding
  21. >|> >things up is to use triple buffering rather than double buffering.
  22. >|> [explanation deleted]
  23. >|> 
  24. >|> Triple buffering is completely useless. (Almost) Here's why.
  25. >|> 
  26. [explanation deleted]
  27. >|> 
  28. [unwarrented preaching deleted]
  29.  
  30.  
  31. >If you sit down with a piece of paper and pencil I think you will see
  32. >that you are actually wrong.  Look at it this way:  with your double
  33. >buffering scheme the CPU sits around and does *nothing* while it waits
  34. >for the next frame.  With triple buffering the CPU starts drawing the
  35. >next
  36. >frame, so it effectively has a head start.
  37.  
  38. [table-deleted]
  39.  
  40. >I know this "chart" is a confusing mess, but if you work it out
  41. >yourself,
  42. >you'll see the point.
  43.  
  44. >The triple buffered display gets slightly ahead of the double buffered
  45. >display, yielding a higher frame rate.
  46.  
  47. I do see the point.  But what are you going to do with about 25 frames
  48. when the frame rate is 30?  I don't think showing 25 frames with some
  49. repeats will be much better animation than showing 15 frames with all
  50. repeats.
  51.  
  52. Of course, we are assuming that the redraw rate is just longer than the
  53. frame rate.  Of course if the redraw rate was a lot longer then triple
  54. buffering could improve things. An example would be if we could increase
  55. from 4 to 5 redraws per second.
  56.  
  57.