Fix count of elements in buffer

Fix count of elements in buffer

There can be one extra element at the end even if an entire stride doesn't fit.

BUG=
TEST=

Committed: http://code.google.com/p/angleproject/source/detail?r=884

[Nicolas.Capens, 2011-11-18 16:49:58]

Nice observation.

I wonder if the following formula gives us the same result without requiring
boolean logic:

count = (bufferSize - offset % stride + (stride - typeSize)) / stride

The idea is that offset % size is the position of the first element that can be
read, so we have to subtract that from the buffer size, and (stride - typeSize)
is the space after the last element that we won't be reading anyhow, so we can
add that.

Does that make sense? We obviously need to get this right since it's worse to
report too many elements than too few.

(P.S.: I had to use my GMail account due to a bug in Rietveld)

[John Bauman, 2011-11-18 17:11:58]

On 2011/11/18 16:49:58, Nicolas.Capens wrote:
> Nice observation.
> 
> I wonder if the following formula gives us the same result without requiring
> boolean logic:
> 
> count = (bufferSize - offset % stride + (stride - typeSize)) / stride
> 
> The idea is that offset % size is the position of the first element that can
be
> read, so we have to subtract that from the buffer size, and (stride -
typeSize)
> is the space after the last element that we won't be reading anyhow, so we can
> add that.
> 
> Does that make sense? We obviously need to get this right since it's worse to
> report too many elements than too few.
> 
> (P.S.: I had to use my GMail account due to a bug in Rietveld)
Yeah, that seems like it should work. It would also fix the case (broken in the
current code and my patch) where, for example mOffset = 8, stride = 12, typesize
= 12, and buffersize = 24, where count should be 1, not 2.

[John Bauman, 2011-11-18 19:16:52]

Ok, switched to use new logic.

[Nicolas.Capens, 2011-11-18 19:19:08]

Looks ok to me.

[dgkoch, 2011-11-18 19:23:14]

LGTM