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

Re: [Public WebGL] Should texSubImage2D accept null like texImage2D does?

On Sat, Mar 10, 2012 at 9:42 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
> Hi,
> This is another corner case found by Ms2ger. Currently, Firefox generates an exception when the texSubImage2D signature taking ArrayBuffer is passed null for the arraybuffer object.
> But looking at the spec, it says: "See texImage2D for restrictions on the format and pixels arguments." Which seems to imply that null should be accepted, as it is for texImage2D? And handled in the same way? What do other browsers do?

Oh boy. Another good catch. The conformance tests completely miss this
case as does WebKit's WebGL implementation. Based on the intent in
WebKit's code, I suggest that we amend the spec and conformance tests
in the following ways:

 1. Update the specs for texImage2D and texSubImage2D taking
ArrayBufferView to state that if an ArrayBufferView is passed which
does not contain enough data to satisfy the call, an INVALID_OPERATION
error is generated. (This is already being enforced at least by
conformance test textures/tex-image-with-invalid-data.html if not

 2. Update the texSubImage2D spec taking ArrayBufferView to state that
if null is passed, an INVALID_VALUE error is generated.

The rationale for the second is that it's obvious that no developers
are currently relying on passing null to texSubImage2D in order to
reset a sub-rectangle of a texture to transparent black. I don't think
there's a reason to support this.

I vaguely recall a decision some time ago to not enforce the behavior
of passing null to the texImage2D and texSubImage2D variants taking
HTMLImageElement, etc., because doing so conceptually exercises the
overload resolution algorithm in Web IDL rather than the behavior of
WebGL. Tim, do you remember this? It looks like an arbitrary method
will be called according to the Web IDL spec. Perhaps we could enforce
that INVALID_VALUE is passed in these cases since all of the overloads
should have the same behavior. WebKit already does this for what it's

Thoughts? Would you support clarifying at least points 1 and 2 above
in the in-progress 1.0.1 spec and conformance tests too? It seems like
a corner case worth fixing up.


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