Save offset from lookupAttributes in prepareVertexData

Save offset from lookupAttributes in prepareVertexData

Avoids calling lookupAttributes twice per attribute.

BUG=
TEST=

[nicolas, 2011-10-13 13:21:27]

Frankly this makes it quite hard to understand the code (which already wasn't
exactly trivial to begin with), which makes future maintenance more complicated.

Perhaps instead of reducing the number of lookupAttributes() calls, that method
itself can be optimized? Currently the cache is an STL vector that is searched
through linearly. Since currently every attribute can only have one cache entry
(I think), the cache could instead be a simple array indexed by attribute
number. That way it's fine if lookupAttributes() is called multiple times.

[John Bauman, 2011-10-13 18:00:11]

On 2011/10/13 13:21:27, nicolas wrote:
> Frankly this makes it quite hard to understand the code (which already wasn't
> exactly trivial to begin with), which makes future maintenance more
complicated.
> 
> Perhaps instead of reducing the number of lookupAttributes() calls, that
method
> itself can be optimized? Currently the cache is an STL vector that is searched
> through linearly. Since currently every attribute can only have one cache
entry
> (I think), the cache could instead be a simple array indexed by attribute
> number. That way it's fine if lookupAttributes() is called multiple times.

Currently the static buffer still works if the attribute number changes but the
actual attribute remains the same, for example if two passes use the same
attributes but skip some and bind the others in a different order. It'd be nice
to keep that.

Also, I found that the main expense seems to be comparing a VertexElement to
make sure it's the one you want. I tried a number of methods to make
lookupAttributes faster, but in the end they were all limited by that
comparison, so I figured it's better to try to avoid it completely.

[nicolas, 2011-10-25 19:00:56]

On 2011/10/13 18:00:11, John Bauman wrote:
> Currently the static buffer still works if the attribute number changes but
the
> actual attribute remains the same, for example if two passes use the same
> attributes but skip some and bind the others in a different order. It'd be
nice
> to keep that.

Sure, it's definitely worth keeping support for that. But the most typical case
will use the attributes in the exact same order for every draw. So if the cache
was a fixed array instead, with entries stored at the attribute index that was
used when the static buffer was created, then you could simply start the search
from the attribute index instead of always from the start of the STL vector that
is currently used.

I also noticed that the element type can only be 16-bit, the size is 0-4 (3
bits), stride is limited to 255 (8 bits), and normalized is a boolean. So you
could potentially store the whole element format in one 32-bit variable, instead
of the current 4 x 32-bit variables. That should speed up the comparison itself.

Anyhow, is there still a need to optimize lookupAttributes, now that other major
hotspots have been optimized?