I just read this on http://blog.tojicode.com/2013/09/whats-coming-in-webgl-20.html :
drawRangeElementsAnd in the spec, http://www.khronos.org/registry/webgl/specs/latest/2.0/
/* TODO(kbr): argue against exposing this because it can't safely offer better performance than drawElements */ void drawRangeElements(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, GLintptr offset);Could you explain what the concern is here?
Already for drawElements in WebGL 1.0, implementations must be able to quickly compute the maximum in any interval within the bound element array, and need to be able to react quickly to partial element array buffer updates with bufferSubData. There is no additional difficulty with extending that to also be able to compute the minimum, that's really the same problem that we already had to solve before! Having both the maximum and the minimum, we have what we need to validate the drawRangeElements call, so we can just pass it on to the GL. Am I missing something?
For example, in Mozilla's implementation, the validation for drawElements already in WebGL 1.0 uses a binary heap (a binary tree stored contiguously in memory) to compute the maximums. Just doing the same for minimums should not be a problem. Memory usage isn't a problem either, as the element array entries are grouped by 8 before constructing the tree, so the tree is fairly small compared to the original buffer.
The code is very self-contained and reusable (see the big comment in the .cpp)