Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!fluke!ssc-vax!voodoo!zombie
From: zombie@voodoo.UUCP (Mike York)
Newsgroups: comp.sys.sgi
Subject: Re: 4D/70 question
Message-ID: <527@voodoo.UUCP>
Date: 8 Feb 89 16:19:25 GMT
References: <8902071551.AA16241@adt.uucp>
Reply-To: zombie@voodoo.UUCP (Mike York)
Organization: Voodoo Graphics Project
Lines: 27

In article <8902071551.AA16241@adt.uucp> madd@adt.UUCP (jim frost) writes:
>
>The 3000's still seem to outperform the 4D's in some things, at least
>with our product, but that may be a result of the design of our
>graphics routines.

On a similar note, we've found some things to run significantly slower
on a 4D/70 GT than on our 4D/70 G's, particularly picking (which is all
important in our application).  With 3.0.1, picking was 6 times slower
on the 4D/70 GT.  with 3.1C, picking is only 2 times slower.  Can hardly
wait for 3.1D/3.2/WhateverTheyWantToCallIt :^).  The explanation I got from
SGI is that the architecture of the GT models does not lend itself well
to operations that imply feedback (picking, popattributes, etc).

Ironically, it's beginning to look like the best overall performer for
our application (a technical illustration package) is the 4D/20 Super
(or whatever they call the Eclipse with all the bit planes and the FPA).
The vector graphics are only slightly slower than the 4D/70 G (for our
application), but the raster capabilities are so much better.  It's 
looking like a pretty nice little box.


-- 
Mike York
Boeing Computer Services, Renton, Washington
(206) 234-7724
uw-beaver!ssc-vax!voodoo!zombie