Re: [Public WebGL] drawArrays/drawElements validation cost query

[Benoit Jacob <bjacob@mozilla.com>]

+1 to this: I would be very interested in any plausibly realistic testcase causing Firefox to spend significant time in drawElements validation.

Until it's proven that drawElements is necessarily slow in some cases regardless of implementation in particular browsers, we're just talking about the possibility of browser bugs here. We don't want to add Web APIs to query "is the browser buggy" --- Might as well add a isComputerOn() function.

Firefox's drawElements validation code is here:

http://dxr.mozilla.org/mozilla-central/source/content/canvas/src/WebGLElementArrayCache.h
http://dxr.mozilla.org/mozilla-central/source/content/canvas/src/WebGLElementArrayCache.cpp

There's nothing really fancy here, it's just a binary heap, i.e. a binary tree of integers stored in a compact way in an array.
http://en.wikipedia.org/wiki/Binary_heap

Cheers,
Benoit

On 14-03-11 11:27 AM, Brandon Jones wrote:

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.

--Brandon

On Mar 11, 2014 4:59 AM, "Florian Bösch" <pyalot@gmail.com> wrote:

On Tue, Mar 11, 2014 at 12:43 PM, Olli Etuaho <oetuaho@nvidia.com> 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.