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

Re: [Public WebGL] WebGL IDL includes overloads that are not allowed in WebIDL




On 4/2/12 9:07 PM, Kenneth Russell wrote:
Thanks for pointing this out. For the moment I've resolved this by
making the ArrayBufferView? argument in the first overload
non-nullable. I also changed the bufferData overload taking
ArrayBuffer to make that argument nullable to resolve that resolution
conflict.

Thanks, looks good.

Are you using a tool to discover these issues in WebGL's IDL? If so,
could you please send a pointer to the mailing list? I don't think any
of the web browsers' build process accept vanilla Web IDL, and it's a
big problem that the IDL has never been machine validated.

I'm using a combination of three things:

1) A WebIDL parser; see <http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0001.html>. Note that this is very much a work in progress; I had to comment out some things in the WebGL IDL that it can't handle yet, for example.

2) A code generator based on the output of the parser. This is what caught the [Callback] thing, for example: it parsed fine because the parser allows arbitrary annotations like that, but the interface didn't end up as a callback interface, so the generated code ended up looking wrong (and in particular not compiling). The current version of the code generator lives at <http://hg.mozilla.org/mozilla-central/file/5128e92c536c/dom/bindings>; there is unfortunately no standalone version because the codegen is pretty closely tied to Gecko internals. Some checks (e.g. for validity of overload sets) are currently done in the codegen but should move to the parser at some point.

3) Manual inspection of the IDL, generally around a point that triggered an error in #1 or #2. ;)

In any case, the end game here is to use vanilla Web IDL (possibly with some added annotations in []; the jury is still out on that) as part of Gecko's build process. We're doing it for XMLHttpRequest as of a few days ago, and the WebGL context is one of the next several things we're working on moving over.

I'm not quite sure why this is using a nullable type at all, honestly. For
one thing, the spec doesn't quite define behavior when null is passed.
  OpenGL ES section 2.9 has, for this function, the signature:

  void BufferSubData( enum target, intptr offset, sizeiptr size,
                      const void* data );

and doesn't really define what happens for null |data| (contrast with
BufferData earlier in that section, which explicitly says behavior is
undefined if data is null; the IDL for bufferData doesn't allow a null data
argument, though).

The main question here is one of compatibility; would throwing a TypeError instead of generating an INVALID_VALUE OpenGL error (which some WebGL implementations do) break a significant number of web pages? The answer is probably no, so most likely bufferData should not accept nullable arguments. This question, however, is already being actively discussed on something like two other email threads so let's continue this conversation there.

Sounds good.

-Boris

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