home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17883 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  5.1 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!bunker!nuconvex!starpt!doiron
  2. From: doiron@starpt.UUCP (Glenn Doiron)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Chunky Pixels vs. Bitplanes  (was: Chunky Chip Set...)
  5. Message-ID: <doiron.0k4a@starpt.UUCP>
  6. Date: 28 Dec 92 22:49:53 GMT
  7. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>        <1992Dec28.000531.26783@mpifr-bonn.mpg.de>
  8. Organization: 68K Software Development
  9. Lines: 100
  10. X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
  11.  
  12. In article <1992Dec28.000531.26783@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
  13. > In <jbickers.0m6w@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
  14. > >    You're kidding, right? Sure it's _possible_ to do it with planes,
  15. > >    but don't you think it is easier (and it is definitely faster) to
  16. > >    do it with chunky pixels?
  17. > 
  18. > No kidding. You are right that it is _easier_ with chunky pixels, but it
  19. > isn't necessarily slower. At some point memory bandwidth determines
  20. > execution speed and as long as an image needs the same memory it will
  21. > be processed (about) equally fast. My point is that quite often you
  22. > can live with a lower _depth_ of an image. A chunky pixel display
  23. > will still require processing of the full depth while a planar display
  24. > lets you strip extra bits.
  25.  
  26. Which is correct whenever you want to strip down images to a lower depth.
  27. However, I must inform you that the discussion was about chunky-vs-planar,
  28. not strip-down-to-lower-depth vs. leave-as-is.
  29.  
  30. > >    Well, it should be. Bypassing WritePixel() with chunky pixels will
  31. > >    be quicker than bypassing WritePixel() with planes. There is only
  32. > >    one address calculation, and only one write to memory.
  33. > 
  34. > Well, I'm not really talking about bypassing a routine and killing
  35. > RTG compatibility.
  36. > 
  37. > >> Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills
  38. > 
  39. > >    Any kind of lines.
  40. > 
  41. > Nope. When you start to make lines thicker than 1 pixel you have to
  42. > fill polygons which has some advantages on bitplanes.
  43.  
  44. Nope.  None.  Nada.  Wrong.  Incorrect.  This type of operation will almost
  45. always be faster on chunky.  The best you can hope for w/ planar is a tie.
  46.  
  47. > >> on the other hand can be faster with bitplanes. Not sure about curve drawing
  48. > 
  49. > >    I don't see how flood filling can be faster with planes. The
  50. > >    classic method is mostly ReadPixel() and WritePixel() operations,
  51. > >    which chunky pixels excel at.
  52. > 
  53. > :) Hmm, the classic method is using Flood(). There's nothing that forbids
  54. > the graphics.library to access the hardware and use every optimization.
  55.  
  56. However, a great deal of the traditional graphics functions function much
  57. faster on chunky systems than planar systems.  ReadPixel() and WritePixel()
  58. are two, but others not commonly used on the Amiga (due to a combo of weak
  59. base CPU/planar architecture) are 2d-bitmap-matrix transformations, such as
  60. scaling, rotation, warping, etc.  All these operation are *much* faster on
  61. a chunky pixel architecture.  I can't think of a single 256-color operation
  62. that will be faster on a planar-architecture than a chunky architecture.
  63. Honest.
  64.  
  65. > >> but most curve drawing routines I know need several multiplications per point.
  66. > >    So? There are incremental algorithms for drawing some sorts of
  67. > >    curves (like circles), and having chunky pixels isn't going to
  68. > >    make the calculation of the curve faster, but it WILL speed up the
  69. > >    WritePixel() part of the routine significantly.
  70. > 
  71. > True. But the WritePixel() (noone will use WritePixel !) part is only a
  72. > small part of the rendering operation.
  73.  
  74. Aargh.  Here's a comparison:
  75.  
  76. (256 color mode)  AGA (16-bit accesses)      Chunky (16-bit accesses)
  77.  32-point line:   256 reads 256 writes       32 writes
  78.  
  79.  32-point line,
  80.  2 pixels thick:  512 reads 512 writes       64 writes
  81.  (Why are bitplanes better for this?  Seems like an additional 960 memory
  82.   accesses to me.)
  83.  
  84.  32x32 blit:      1536 reads 512 writes      1024 reads, up to 1024 writes
  85.          or up to 2304 reads 768 writes
  86.  (second case if either source or dest. non-aligned)
  87.  (including transparency/masking)
  88.  
  89.  Scaling: 32x32 image, blow up to 64x64
  90.   convert to chunky: 8192 reads              no-op
  91.   do mathematical xforms                     do mathematical xforms
  92.   convert to bitplane: 32768 reads           no-op
  93.  
  94. OK, now tell me which one will be slower?  I'm not even factoring in the
  95. ridiculous amount of bit-shifting and masking involved in all these
  96. operations for AGA (excluding the 32x32 blit... blitter was assumed).
  97.  
  98. > -- 
  99. > Michael van Elst
  100. > UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
  101. > Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
  102. >                                 "A potential Snark may lurk in every tree."
  103.  
  104. Glenn Doiron (who thinks this chunky vs. planar stuff is hogwash anyways..
  105.               we need both...)
  106. --
  107. Amiga UUCP+
  108. Origin:  uunet.uu.net!starpt.UUCP!doiron (Organization:68K Software Development)
  109.          BIX: gdoiron
  110.  
  111. ** Not enough memory to perform requested operation.  Add 4 megs and retry.
  112.