home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17968 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.5 KB  |  58 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!portal!danb
  3. From: danb@shell.portal.com (Dan E Babcock)
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <C03uC5.15o@unix.portal.com>
  6. Sender: news@unix.portal.com
  7. Nntp-Posting-Host: jobe
  8. Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
  9. References: <1992Dec30.115759.22097@mpifr-bonn.mpg.de> <doiron.0ka3@starpt.UUCP> <1992Dec31.011428.2926@mpifr-bonn.mpg.de>
  10. Date: Thu, 31 Dec 1992 03:43:17 GMT
  11. Lines: 45
  12.  
  13. In article <1992Dec31.011428.2926@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
  14. >In <doiron.0ka3@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  15. >
  16. >Thus bitplane devices are usually same speed as chunky pixel devices. But
  17. >you can scale bitplane devices easily with the obvious performance advantages.
  18. >You can never scale chunky pixel devices.
  19.  
  20.  
  21. Well, that's misleading. If you are talking about a blitter-per-plane type of
  22. architecture, the only one created (a few years ago from National) was a dismal
  23. flop. Too expensive with minimal advantages.
  24.  
  25. >>You are doing the same transformations 8 times, once for each bitplane.
  26. >>This is not 8x the number of transformations?  You deny facts?
  27. >
  28. >Again, with the example of doubling a bitmap you handle multiple pixels
  29. >at a time which exactly compensates for the number of bitplanes.
  30.  
  31. No, it can rarely exactly compensate. The bitplane version of the algorithm
  32. will require the use of more temporary data, slowing it down. The best
  33. case is almost-as-fast. 
  34.  
  35. >Special-case optimizations. Right. But the "special cases" cover most graphics
  36. >operations.
  37.  
  38. Except silly little things like drawing lines. Who'd ever want to draw a line? :-)
  39.  
  40. >>See above.  You still have to clear the other bitplanes.  And some chunky
  41. >>hardware supports color expansion, too, where you take a single-bit image
  42. >>and can expand all 0's to one color and 1's to another.  Of course, a
  43. >>similar thing could be done for planar, but you still have the
  44. >>masking/shifting/bandwidth on unaffected pixels problems.  (Say it 3 times
  45. >>real fast.)
  46. >
  47. >The special hardware cannot magically expand the pixels since the bitmap
  48. >in the frame buffer (VRAM) needs all pixels to be defined. In chunky you
  49. >cannot write single bits into a pixel and have any speed advantage.
  50.  
  51. No, the VRAMs contain a color register. The "1" expands to whatever color was
  52. previously loaded. Again, this allows text writing and polygon filling to be
  53. done 4 times faster than usual.
  54.  
  55. Dan
  56.  
  57.  
  58.