home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18089 < prev    next >
Encoding:
Text File  |  1993-01-03  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!spool.mu.edu!yale.edu!ira.uka.de!Sirius.dfn.de!rrz.uni-koeln.de!Germany.EU.net!mpifr-bonn.mpg.de!specklec.mpifr-bonn.mpg.de!mlelstv
  3. From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <1993Jan4.031543.18522@mpifr-bonn.mpg.de>
  6. Sender: news@mpifr-bonn.mpg.de
  7. Nntp-Posting-Host: specklec
  8. Organization: Max-Planck-Institut f"ur Radioastronomie
  9. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>              <1993Jan3.204843.15155@mpifr-bonn.mpg.de> <doiron.0kmz@starpt.UUCP>
  10. Date: Mon, 4 Jan 1993 03:15:43 GMT
  11. Lines: 49
  12.  
  13. In <doiron.0kmz@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  14. >This is a *general purpose* scaling algorithm.  It uses no predefined
  15. >tables.
  16.  
  17. Correct. It also makes the effect of chunky vs. bitplane quite invisible.
  18. It is however not the preferred method. If the rectangles in question
  19. are large enough it is faster to precalculate the tables and use them.
  20.  
  21. >The rendering is a small fraction on the chunky system, however getpixel()
  22. >and putpixel() on a planar system may even take *more* time than the
  23. >multiplications due to the time needed to ([shift/mask/extract]x8) then
  24. >([shift/mask/insert]x8) do those operations in planar.
  25.  
  26. Hardly. You forget the time needed to calculate pointers from x,y
  27. coordinates.
  28.  
  29. >It's a general purpose algorithm that will scale/rotate bitmapped images.
  30. >It suffers no limitations unlike your precalculated table.
  31.  
  32. And it is not used when performance is an issue.
  33.  
  34. >I can assure you that on a chunky display, that will be the case.  On a
  35. >planar display, that is a different story entirely.
  36.  
  37. While it is different the overhead isn't that high.
  38.  
  39. >Notice how **NO** processors support parallel operations on several
  40. >arbitrary bits at different memory locations.  Even if there were there
  41. >would still be overhead due to the extra data accessed that wasn't even
  42. >considered.
  43.  
  44. You don't need to do operations on several arbitrary bits at different
  45. memory locations in parallel. And, for many things, you don't even
  46. work on single bits because you do not handle a pixel at a time.
  47.  
  48. >Suppose you have a blit that takes 20ms on chunky and 30ms on planar
  49. >(planar is accessing 1/3 more data than neccessary) on a 256 color display.
  50. >Jump up the pixel depth to true-color (32-bit), and you're suddenly wasting
  51. >4x as much time, since now it's taking 80ms on chunky and 120ms on planar.
  52. >Still in a 2:3 ratio, but your time wasted has jumped from 10ms to 40ms.
  53.  
  54. Still don't see your point here.
  55.  
  56. Regards,
  57. -- 
  58. Michael van Elst
  59. UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
  60. Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
  61.                                 "A potential Snark may lurk in every tree."
  62.