All Macs In-Depth Tests
Cheap "No Cost" Trick To Improve Graphics Performance 25-50%

|We were curious what kind of performance hit you get from running millions of colors rather than running your machine at a lower color bit depth. So we broke out MacBench 5.0 and ran a few tests on our newly purchased Revision "B" iMac/233Mhz (ATI RAGE PRO TURBO accelerated 2D/3D graphics  controller and 6MB SGRAM). We were surprised at the amount of the performance hit you take for getting those extra colors and that, although there was a sharp fall off in performance going from thousands to millions of colors, there was  basically no performance difference between thousands of colors and 256 colors or greys! Anyone who can explain this disparity to us we would be glad to be enlightened.

MacBench 5.0 Graphics Mix Results
Longer Bars Equals Better Performance

 

Then  we thought we would run a few "real world" tests to see what we would find.....

Scrolling Tests
Shorter bars are better

 

 



Again an unexplained curiosity here, in that scrolling was much faster at fewer colors when a image file was involved, but when a text document was used for testing, the higher color bit depth won out in the scroll test. We ran the test several times with virtually the same result each time.

And what kind of visual hit do you take from running fewer colors? ........

 

Image at 256 colors

Image at thousands of colors

Image at millions of colors

.Conclusion: Watching the MacBench graphics tests go through their paces at millions of colors it was obvious how much more sluggish and jerky they were than at thousands of colors.  Unless you are doing a lot of detailed work with images or applications that require millions of colors you are wasting a lot of the performance of your machine by running it with the color bit depth set to millions of colors. You can recapture significant  performance by setting the monitor to thousands of colors and easily toggle it up to millions of colors using the Power Strip  should the need arise.

Notes: 
 
  • Graphics performance difference under different color bit depths may be dependent on your graphics subsystem and thus may vary machine to machine

  •  
  • Changing the amount of colors will not improve the processing power of your machine just how fast things are drawn on your screen
  •  
    Commentary:
    Just for some more data points, here's a report on the two video cards I run in my machine.  The computer is a Power Macintosh 7500 with a Railgun G3 accelerator running at 308.5 MHz.  The main video card is an 8 MB MacTell Vision3D Pro II Lite.  The secondary video card is a 4 MB ATI XClaim VR (one of the _original_ ones).  (I use this card because my built-in video went flaky after I put in the G3 upgrade, and I wanted video out for use with a VCR.  I keep mostly palettes on it so speed is not as important.)

    I didn't have MacBench 5.0 handy so I used Norton System Info.  I didn't bother quitting applications, I left the ones I happened to be using at the time of the test open.  Here are the composite scores:

    Vision3D running at 16-bit: 457
    Vision3D running at 24-bit: 286 

    Result: Almost 60% speed improvement overall, certainly more than I expected!

    XclaimVR running at 16-bit: 213
    XclaimVR running at 24-bit: 81 

    Result: A 260% speed improvement!  I _never_ expected this!

    It's interesting to look at the various specific and see which tests differ the most and by how much.  Interestingly, the Vision3D card was slightly faster at rounded rectangles in 24-bit mode (5837 vs. 5621) and significantly faster drawing lines that way (35463 vs 22877).  With the ATI, everything was faster in 16-bit mode.

    I thought the lines results on the V3D was interesting but the test draws mostly diagonal lines.  I would not be surprised to find out that horizontal and vertical lines are faster (most video accelerators special-case them) but I don't have a way to bench that.

    The Vision3D is more than fast enough in millions of colors, and I run Photoshop a lot, so I'll probably keep it set that way for convenience. Or maybe not.  I'm not sure if the speed difference is noticeable since the card was so fast in millions!  I'll probably run it at Thousands for a few day then go back to Millions and see if I notice any difference. I've found this the surest way to determine subjective performance, since we acclimate to acceleration so quickly.  <g>

    The speed improvement on the XClaim, however, is a very welcome one.  I'm kicking myself for not benching this myself earlier.  Indeed, sometimes the obvious and free things are worth looking into.

    -- Jerry Kindall   
    mailto:kindall@mail.manual.com   
    Technical Writing Manual Labor    
    http://www.manual.com 




    Larry Rosenstein wrote:

      "SGRAM). We were surprised at the amount of the performance hit you  take for getting those extra colors and that, although there was a  sharp fall off in performance going from thousands to millions of  colors, there was  basically no performance difference between  thousands of colors and 256 colors or greys!"

    I think it's clear why there's a sharp difference between thousands and millions: you move twice as much data in the millions case. (Even though millions is only 24 bits per pixel, I think a pixel is represented with 32 bits, and QuickDraw will still move those extra 8 bits around.)

    I'm not certain why there's not much difference between thousands and 256 colors, but I would guess it's because in 256 colors, QuickDraw tries to find the best matching colors and will dither colors in some cases, which takes extra time.  Thousands and millions use a direct color model, so this isn't necessary.

      "Again an unexplained curiosity here, in that scrolling was much  faster at fewer colors when a image file was involved, but when a  text document was used for testing, the higher color bit depth won  out in the scroll test. We ran the test several times with  virtually the same result each time."

    I can see why the image scrolling would be this way, because the time should be directly proportional to the number of bytes being transfered.  I'm not sure why the text scrolling is reversed.  It could be that something in the text or font subsystems is optimized for 32-bit chunks.  It would be interesting to try the same test in another text app.