home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17997 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.8 KB  |  63 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mpifr-bonn.mpg.de!speckled.mpifr-bonn.mpg.de!mlelstv
  3. From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <1992Dec31.174137.10865@mpifr-bonn.mpg.de>
  6. Sender: news@mpifr-bonn.mpg.de
  7. Nntp-Posting-Host: speckled
  8. Organization: Max-Planck-Institut f"ur Radioastronomie
  9. References: <1992Dec30.115759.22097@mpifr-bonn.mpg.de> <doiron.0ka3@starpt.UUCP> <1992Dec31.011428.2926@mpifr-bonn.mpg.de> <C03uC5.15o@unix.portal.com>
  10. Date: Thu, 31 Dec 1992 17:41:37 GMT
  11. Lines: 50
  12.  
  13. In <C03uC5.15o@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
  14. >In article <1992Dec31.011428.2926@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
  15. >>Thus bitplane devices are usually same speed as chunky pixel devices. But
  16. >>you can scale bitplane devices easily with the obvious performance advantages.
  17. >>You can never scale chunky pixel devices.
  18.  
  19. >Well, that's misleading. If you are talking about a blitter-per-plane type of
  20. >architecture, the only one created (a few years ago from National) was a dismal
  21. >flop. Too expensive with minimal advantages.
  22.  
  23. I am talking about a single blitter architecture. The simple point that
  24. you need less memory for less bitplanes makes an operation faster.
  25.  
  26. >>>You are doing the same transformations 8 times, once for each bitplane.
  27. >>>This is not 8x the number of transformations?  You deny facts?
  28. >>
  29. >>Again, with the example of doubling a bitmap you handle multiple pixels
  30. >>at a time which exactly compensates for the number of bitplanes.
  31.  
  32. >No, it can rarely exactly compensate. The bitplane version of the algorithm
  33. >will require the use of more temporary data, slowing it down. The best
  34. >case is almost-as-fast. 
  35.  
  36. Why would it need more data ?
  37.  
  38. >>Special-case optimizations. Right. But the "special cases" cover most graphics
  39. >>operations.
  40.  
  41. >Except silly little things like drawing lines. Who'd ever want to draw a line? :-)
  42.  
  43. And who fill an area by writing single pixels ?
  44.  
  45. Fortunately, line drawing usually has to handle less data (you won't try to
  46. fill the screen with vertical lines..).
  47.  
  48. >No, the VRAMs contain a color register. The "1" expands to whatever color was
  49. >previously loaded. Again, this allows text writing and polygon filling to be
  50. >done 4 times faster than usual.
  51.  
  52. So you write a bitplane to VRAMs and get the whole pixel depth ? Would
  53. be identical to write to several bitplanes at the same time. I can't seen
  54. anything chunky or bitplane specific here. Just a method to increase
  55. bus bandwidth.
  56.  
  57. Regards,
  58. -- 
  59. Michael van Elst
  60. UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
  61. Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
  62.                                 "A potential Snark may lurk in every tree."
  63.