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
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.
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
Technical Writing Manual Labor
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
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.