[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
- To: Boris Zbarsky <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] WebGL IDL includes overloads that are not allowed in WebIDL
- From: Kenneth Russell <email@example.com>
- Date: Wed, 4 Apr 2012 16:26:53 -0700
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=XrXsPZHfsG3BXwIUnzHOlq8ad4HavhXRG5et0JouKWg=; b=lixuhnoT3RfVaOXGkzCaIZSA4NgM6zKbMF17rV/5mG0//6qM81cNeANCOy0BqYQufV 9GUowTbtl/PZmv65qA76LrO6+176Kee238HsTw63M6xljElf+5GNgML6FFJtKkA0xQN/ X2Qq57+QvmLf7ZUxctsOMMQGfMREq7Pgzz/ZiiTGiMPO7C60Uw1Ap7tRVhjoYea6eu69 QtrZjQ9xin/x6VKOE+EJ9vl8X50LEcqRdSw2h4qKfwn0fzgJX713kPx10Q+bhs1FtVxT JUuDVGSyb3GXx0mZqRwX16nl59ZNnuCW0I6m2dbiBbjrovu5yZrqnHI6BfnNWwvPmWeg DLCA==
- In-reply-to: <4F7B0797.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4F79B56F.firstname.lastname@example.org> <CAMYvS2eTrLDGt=HwqtYySfNN9v0D1O+-4WipMxMUFx9WHu6CsQ@mail.gmail.com> <4F7B0797.email@example.com>
- Sender: firstname.lastname@example.org
On Tue, Apr 3, 2012 at 7:22 AM, Boris Zbarsky <email@example.com> 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
> 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
> 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
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.
>>> I'm not quite sure why this is using a nullable type at all, honestly.
>>> 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
>>> 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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: