Do all browsers exhibit similar performance penalties for drawElements? I seem to recall that Mozilla has mentioned in the past that they had a fairly novel "tree-based" validation approach that should have made repeated validations faster. Does Firefox have better performance characteristics in the pathologically bad cases, because if so Chrome (and the other browsers) should look at imitating their logic.
On Tue, Mar 11, 2014 at 12:43 PM, Olli Etuaho <[email protected]> wrote:That being said, we're not likely to get rid of the index buffer checks in all situations, so this discussion is also relevant. However, whether the index buffer needs to be revalidated depends on how the browser has implemented the requirement to return INVALID_OPERATION when indices are out of range.There are a lot of potential ways to make it faster than the naive approach, and the return value of drawWouldValidateVertexData could thus vary between browsers or even be meaningless on certain kinds of implementations, like if a lot of caching was done when buffer data is changed. So I'd be hesitant to add something like this to the spec.
Without consistent behavior in regards to validation, using drawElements is a minefield. I think it's untenable to have a function in an API that's a tripmine. So either validation behavior is made consistent so that a developer can adjust his usage not to trigger it, or drawElements has to be removed.This issue mucks up peoples code and makes WebGL run slow in an unpredictable manner. It's an endless source of issues and frustrations for everybody who starts with WebGL. And it's the cause why every who does WebGL for a while, avoids using drawElements entirely. It's also the reason why a lot of code that people put out with WebGL run inexplicably slow, and leave a bad impression for web visitors.