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

[Boris Zbarsky]

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 pub...@
To unsubscribe, send an email to maj...@ with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------