home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / graphics / 14233 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  1.5 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!darwin.sura.net!newsserver.jvnc.net!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!dkuug!diku!torbenm
  2. From: torbenm@diku.dk (Torben AEgidius Mogensen)
  3. Newsgroups: comp.graphics
  4. Subject: Re: 256 color faster than 16 color ...why?
  5. Message-ID: <1993Jan26.104741.13453@odin.diku.dk>
  6. Date: 26 Jan 93 10:47:41 GMT
  7. References: <C1FvJp.Hw9@acsu.buffalo.edu>
  8. Sender: torbenm@tyr.diku.dk
  9. Organization: Department of Computer Science, U of Copenhagen
  10. Lines: 21
  11.  
  12. tef@acsu.buffalo.edu (Tom Frisinger) writes:
  13.  
  14. >Hello,
  15. >    I've done some tests and found out that 256 is indeed much faster
  16. >than 16 color at the same resolution.  Why is this?  I tested
  17. >320x200x16 vs. 320x200x256, and 640x480x16 vs. 640x480x256, and
  18. >800x600x16 vs. 800x600x256.  I figure that that covered all the
  19. >memory ranges pretty well.  The 256 color out performed the 16 color
  20. >by anywhere from 10%-40%!!!   The only possible explantion I can
  21. >think of is that with 256 color they can to fast byte operations on
  22. >memory vs. messing around with 4bits and shifting and all that.  Is
  23. >this theory at all on the right track?
  24.  
  25. You haven't specified what system you ran the tests on and which
  26. operations you tried. But, yes, I do believe your theory is right.
  27. Operations that require access to individual pixels (e.g.
  28. line-drawing) will be sped up if you can avoid masking operations at
  29. every step. Bitmap moves etc. will usually be faster with 4bpp than
  30. 8bpp, as masking needs only be done at the edges.
  31.  
  32.     Torben Mogensen (torbenm@diku.dk)
  33.