home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18064 < prev    next >
Encoding:
Text File  |  1993-01-02  |  4.8 KB  |  111 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!mcsun!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: <1993Jan3.035112.5898@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: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>            <1993Jan1.141207.20262@mpifr-bonn.mpg.de> <doiron.0kil@starpt.UUCP>
  10. Date: Sun, 3 Jan 1993 03:51:12 GMT
  11. Lines: 98
  12.  
  13. In <doiron.0kil@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  14. >... and you still haven't convinced me that chunky isn't faster.  As was
  15. >said before, the best you can hope for is break-even, and far more often
  16. >chunky will be faster - the bigger the blit, the smaller the difference.
  17.  
  18. The difference vanishes if the bitplanes are well aligned. Otherwise, except
  19. for tiny bitmaps such as single pixels, the difference is neglible.
  20.  
  21. Remember, it is a tiny difference since only borders are affected in most
  22. operations. Bitplanes will win if you can strip whole bits from all pixels
  23. (i.e. cut down on pixel depth).
  24.  
  25. >As I said, you lose all the performance gains VRAMS were supposed to give
  26. >you in the first place, since you can't use the serial registers for video
  27. >fetch in planar setups.
  28.  
  29. I wouldn't be so sure :)
  30.  
  31. >Chunky has this property too, although only to a power of two.  This
  32. >however, is not nearly good enough justification for all the penalties you
  33. >get in planar doing everyday operations.  Why use a lesser number of colors
  34. >when you can use more for the same, if not better, performance?
  35. > 
  36.  
  37. Using more colors (more bits per pixel) will always degrade performance.
  38. But in bitplanes you could f.e. use 1024 colors instead of either 256 or
  39. 65536.
  40.  
  41. >No.  It is not.  You are doing N time the amount of work in planar, where N
  42. >is the number of planes.
  43.  
  44. Sorry, not at all.
  45.  
  46. >Best of luck to you.  You are talking really expensive hardware now.  Not
  47. >something you'd tack onto an Amiga, or anything, since chunky is here now,
  48. >costs less, and doesn't have any of these deficiencies to which your
  49. >special-purpose hardware would address.
  50.  
  51. >Nope.  "Special case".  You can't use the same algorithm to stretch that
  52. >32x32 image into, say, 64x57 or shrink it to 17x13.  You might be able to
  53. >do 64x32 or 32x64.  But that's still a special case optimization.
  54.  
  55. Well, it is a bitmap scaling by an integer factor. Anything else needs
  56. filter operations.
  57.  
  58. >Shifting is too slow on almost any general purpose processor, not just the
  59. >68000.  Irregardless, you need to do a lot of shifting/masking, which isn't
  60. >going to be free on --any-- processor, although custom chips can go a long
  61. >way towards hiding this via pipelining/superpipelining.
  62.  
  63. It isn't a long way. There's really no problem to hide shifts behind
  64. memory accesses if you stay with reasonable word lengths. Maybe a 128bit
  65. barrel shifter would be too slow.
  66.  
  67. >Can you use that table to do another transformation, as noted above?  No.
  68. >It's a special case optimization.
  69.  
  70. Can you use your chunky bitmap scaling routine for another transformation ? 
  71.  
  72. >few break-even cases.  Sometimes it will even be faster on chunky *even
  73. >with a reduced scale for planar*, since chunky doesn't need 'bit
  74. >thrashing'.
  75.  
  76. "Doesn't need" is wrong unless you operate on a memory that is one
  77. pixel 'wide'. You hardly do.
  78.  
  79. >In all cases, you've admitted that chunky is faster than planar (w/
  80. >exception of you special case optimization where it breaks even).  I rest
  81. >my case.
  82.  
  83. ...and silently forget depth scaling.
  84.  
  85. >Would help if you didn't delete too much from the above references.
  86. >Plotting an alternating color horizontal line will still be (w/ 8-bit
  87. >color) 8x faster on chunky than planar.  Plotting every other pixel a
  88. >different color isn't going to make planar faster.
  89.  
  90. Plotting an alternate color horizontal line is same speed. You simply
  91. determine the pattern you have to mask through.
  92.  
  93. >:)  Look, if you want a 128-color display, I won't forbid you from using a
  94. >planar architecture.  However, drawing a line will be far faster on a
  95. >256-color chunky than a 128-color planar display.  If you need a
  96. >4,16,256,65536, or true-color display, however, your losses using planar
  97. >will be even more dramatic as the number of colors goes up, since you are
  98. >wasting 2x, 4x, 8x, 16x, or 32x the amount of time accessing irrelevant
  99. >data (still not counting shifting/masking).
  100.  
  101. No. With single pixel lines the losses are determined by the word length,
  102. not the number of planes. Wether you write 8bits per pixel or 24bit per
  103. pixel. The _ratio_ is still the same.
  104.  
  105. Regards,
  106. -- 
  107. Michael van Elst
  108. UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
  109. Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
  110.                                 "A potential Snark may lurk in every tree."
  111.