home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / graphics / research / 396 < prev    next >
Encoding:
Internet Message Format  |  1992-12-18  |  2.4 KB
  1. Path: sparky!uunet!gatech!mailer.cc.fsu.edu!sun13!well.sf.ca.us
  2. From: rms@well.sf.ca.us (richard marlon stein)
  3. Newsgroups: comp.graphics.research
  4. Subject: Re: comp.graphics.research
  5. Summary: Analog I/O ain't the problem.
  6. Message-ID: <11566@sun13.scri.fsu.edu>
  7. Date: 17 Dec 92 17:17:23 GMT
  8. References: <11561@sun13.scri.fsu.edu>
  9. Sender: news@sun13.scri.fsu.edu
  10. Organization: Whole Earth 'Lectronic Link
  11. Lines: 39
  12. Approved: murray@vs6.scri.fsu.edu
  13. X-Submissions-To: graphics@scri1.scri.fsu.edu
  14. X-Administrivia-To: graphics-request@scri1.scri.fsu.edu
  15.  
  16. In article <11561@sun13.scri.fsu.edu> chrisg@cbmvax.cbm.commodore.com (Chris Green) writes:
  17. >
  18. >    Has anyone ever attempted to take advantage of the 
  19. >"infinite-frame-rate" of raster scan devices, particularly video?
  20. >What I mean by this to render your animation with the knowledge
  21. >that each pixel is (for instance) 35ns later than the preceeding
  22. >pixel, and that each scan-line is ~63uS later than the preceeding
  23. >one. Given appropriate temporal filtering, and a general enough
  24. >4-d ray-tracer, shouldn't this provide a potential for improved
  25. >quality? Is anyone familiar with any research or applications
  26. >of this? I'm familiar with Don Mitchell's paper on interlace
  27. >and chroma filtering for video.
  28. >
  29. >
  30. >--
  31. >Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
  32. >Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
  33.  
  34. Try muxing the outputs from 1000 framebuffers into a single analog stream.
  35. I would rather pass on this approach.  The PixelFlow box captures the output 
  36. from a composition network rated at 4 Gbytes/s into a single frambeubffer.
  37.  
  38. I don't believe this approach is truly scalable either, since its still
  39. an example of the N to 1 mux problem.  So it is, in my opinion, contention
  40. limited (the laws of physics won't cooperate and provide infinite digital
  41. bus or network bandwidth).
  42.  
  43. I advocate a tessellated display approach myself, where each tessellation
  44. element owns a processor, framebuffer, and display.  The trick is to coordinate
  45. the system temporally.  The scalable concurrent visualization system trades
  46. contention for asynchronous execution.
  47. --rick
  48. -- 
  49. Richard Marlon Stein, Internet: rms@well.sf.ca.us
  50. To those who know what is not known;  The Chronicles of Microwave Jim!
  51.  
  52. --
  53. Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
  54. Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
  55.