Re: [glean-dev] Quick comments about geomrend and geomutil

[Brian S. <br...@gl...>]

At 10:59 AM 12/21/00 -0800, you wrote:
>geomrend looks pretty nice.  I did want to raise one warning flag,
>though.  As GLVERTEX_MODE rendering is currently handled, a lot of
>cycles are spent checking the data format, fetching data, etc.  This
>isn't a problem for correctness tests, but it introduces enough
>overhead that we should be wary of using it for performance tests.

Yes.  I wrote geomrend just to work for now; it definitely isn't optimal 
for performance.  Good point on watching out for using it for performance 
tests.  As far as glVertex-style rendering, I suspect it'll become even 
more important as ISVs use non-polygonal dynamic representations that can 
be converted to polygonal representations iteratively (like bezier patches 
or whatnot) as it allows for far better pipelining between the CPU 
generating the polygons and the graphics card rendering them.  So, yes, 
it's worth fixing up.  I'd probably just validate the data once and store a 
pointer and use that; going as far as using Duff's Device, well... Duff's 
Device still scares me. ;-)

>About geomutil:  In the new sphere-generation utilities, don't worry
>about returning the address of the first element of a vector to
>represent the start address of an array.  I hear ANSI is going to
>standardize that as part of the required semantics for vectors.

Good to hear.  Given the STL requirements on running times, the only way 
for vector not to store the data in a contiguous array like that is if it 
does something gratuitous or stupid, like storing the data backwards, or 
arbitrarily padding it, or something.

.b