home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18135 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  3.2 KB
  1. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!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.0kq1@starpt.UUCP>
  6. Date: 4 Jan 93 23:03:17 GMT
  7. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>               <1993Jan4.031543.18522@mpifr-bonn.mpg.de>
  8. Organization: 68K Software Development
  9. Lines: 60
  10. X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
  11.  
  12. In article <1993Jan4.031543.18522@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
  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.  
  63. Since you have agreed to all the points I have made, I see no point in
  64. continuing this discussion.  Have a nice day!
  65.  
  66. Glenn Doiron
  67. --
  68. Amiga UUCP+
  69. Origin:  uunet.uu.net!starpt.UUCP!doiron (Organization:68K Software Development)
  70.          BIX: gdoiron
  71. ** Not enough memory to perform requested operation.  Add 4 megs and retry.
  72.