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

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




On 2012-03-11 05:48, Kenneth Russell wrote:
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
others.)

  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
worth.
Yeah, if you leave the 6th parameter out it is tricky to tell if you tried to call the version taking 5 numbers and an object (HTMLImageElement) or the version taking 8 numbers and an object (TypedArray). In our implementation we would assume 0/null for the missing parameters and the call would match both versions. In that case we are highly likely to choose the one which does not cause an error.

I think there has been quite a bit of work on this in WebIDL since we last looked at it, so it might actually be better specified now, but even if it is it would IMO mostly be a conformance test of WebIDL and not of WebGL. (I am also not sure if I like INVALID_VALUE or an TypeError exception better in this case)

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.
I agree, it is something we should clarify. I'm pretty sure we currently throw a TypeError for passing null to the TypedArray version of texSubImage2D right now (so we handle 2. in a different way). Changing it to raising a gl error should be easy, but I am not sure that is better.

In case 1. (not enough data) we already generate INVALID_OPERATION, I actually thought the spec already said that but I can't find it so I guess not :).

//Tim


----------------------------------------------------------- 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 -----------------------------------------------------------