>1) Am I out of line expecting faster than this?

Two seconds seems pretty darn fast to me. I still think the slowest thing
on my Mac is the carbon based device thats pushing the mouse around.

>2) Is drawing to a GWorld actually faster than to the screen perhaps?

Way back when in IB, Ross did a test of drawing to the window and to a
gWorld. Takes exactly the same amount of time to draw the image in those
days so I doubt its changed much. Matter offact we found the gworld was
slightly slower off the bat when, after you created the image in a gworld,
you still have to copybits it to the window (and depending on the transfer
method used, that can be slow as well).

Now, if you only needed the image once, or you only intend to scale it
magrinally, I'd flatten all those polys in a gworld, save that file and use
it to simply blast the image to the screen. Very fast indeed. i.e. if you
scrolled 10 times in a direction and all you were doing was copybits to the
window, it would be way faster than re-drawing all the poly again.

So, it largely depends on the how the remainder of your program works. Lots
of scrolling and things, stick it in a gworld. Show it once and forget it,
leave it at polys.

>3) Does the non-PPC nature of FB-II come into play here. Or should
>Quickdraw (I assume it's native by now)  operate at full speed once the
>CALL is placed?

From what I've gleaned here on the list and others, most of QD is native
but the bottlenecks are still there depending on the function in QD you're
using. Maybe its time to draw using on the 3Dfx cards with the fancy
polys....;-) Kidding.

>4) Here's where it gets interesting.  I just got a super-duper Mactell
>Vision Pro ...blah blah  graphics accelerator card which advertises among
>other things, Quickdraw enhancement.
>Guess what?  In this instance it does nothing!  Nothing? Well maybe it
>slows things down a hair.

Well, there's 2D accelerators and 3D accelerators. The first type is the
one that will affect QuickDraw. The second is what you see in the games
world in anything from 640x480 to about 1000 x 1000 (depending on the
amount of memory in the 3D card). All cards are not created equal.

Connectix mentions in their VPC docs that an external PCI video card is not
as fast as the built in video. And they suggest its more than just a minor
point. I did some testing of my own with an ATI XClaimVR card. Removed the
extensions, 2D (scrolling and regular Mac work was a dog). Put the
accelerator extensions back in and it speeded up things immensely. BUT even
with all the so called "acceleration" ATI could muster, built in internal
video was faster. On the other hand (four fingers; one thumb), built in
video is horrible for 3D acceleration.

>Any clues as to what's going on/what my expectations should be?

Probably like the rest of us, the only way is to write a test routine and
see if its what you thought it would be. I end up with more test routines
than code sometimes. One of my fav test routines was to write my own super
list scrolling code. Gave up eventually but none the less, here's how that
started.

You have a list of items. Now on a medium list (say about 30 items in a
chicago font; 30-40 chars on a line), when the user scrolls, you starting
drawing at the top item and go. Works pretty good. But I thought I would be
really clever and use the toolbox SCROLLRECT. If the user scrolled UP or
DOWN, I only had to draw the ONE new item at the TOP or the BOTTOM of the
list. I just blockmoved (scrollrect) up or down and refreshed the one line.

I was so pleased with my ingenuity until I timed it. Scrollrect isn't fast.
Matter of fact on a medium list its the same speed as if you simply re-drew
every list item starting at the top. Where it works best is a LONG list. So
for all that time in writing the code, I ended up with exactly the same
speed. However, the one benefit of using SCROLLRECT is that its a much
smoother update.

So after several hours of coding, I found speed is still very elusive. Now,
I am happier if it just works...;-)

Mel Patrick
mel@...