[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 Tue, Apr 3, 2012 at 7:22 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

This is very exciting. It would be great if WebKit also moved in the
direction to use true Web IDL.

Please post any further issues you find.

-Ken


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