[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Error catching with getBufferSubData

I disagree:
1) This is inconsistent with the rest of the API. (This is how ReadPixels works) (Not that I like the current API's handling of errors!)
2) This causes getBufferSubData to drift from any previous iteration of glGetBufferSubData in the GL specs.
3) The mapping can only fail for garbage-in-garbage-out reasons, or GL_OOM. We don't give any other GL_OOM sources this same benefit.
4) This forces synchronization between WebGL content calls and the actual driver calls. (Shouldn't this be particularly bad in Chrome's arch?)

On Mon, Jun 15, 2015 at 4:04 PM, Kenneth Russell <kbr@google.com> wrote:

Thanks for catching this oversight. Amending the spec to return a
boolean (and stating that the passed ArrayBuffer is unmodified in this
case) sounds good.


On Mon, Jun 15, 2015 at 3:34 PM, Brandon Jones <bajones@google.com> wrote:
> Something I noticed today while working on Chrome's implementation of this
> function. The implied underlying call to glMapBufferRange may return a NULL
> pointer if the call fails for some reason. This provides a way to do
> efficient error handling. The WebGL function, however, passes in an
> ArrayBuffer to be populated and returns nothing, which means the only way to
> communicate a failure is via getError. It's poor API design to require
> getError calls after an otherwise valid API call just to ensure it worked.
> I propose we update the spec to have getBufferSubData return a GLboolean or
> similar to indicate whether or not the mapping succeeded. That way getError
> calls can be avoided unless we know the mapping failed. Any concerns with
> this approach?
> --Brandon

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl