[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Null return values from create*
- To: Patrick Baggett <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Null return values from create*
- From: Kenneth Russell <email@example.com>
- Date: Wed, 4 Apr 2012 18:00:09 -0700
- Cc: Glenn Maynard <firstname.lastname@example.org>, Gregg Tavares (勤) <email@example.com>, Tim Johansson <firstname.lastname@example.org>, public webgl <email@example.com>, Benoit Jacob <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=DgdEPnaf8Dcm/Ni6mfRZrf3Mif3ema2h3UMK1locefg=; b=NkLX0n0kPQll0kde/O+9JJvL366RigNrhbvUnF1TfRjrqjwbTtEfrUj97BEu1nKOZc lFz1Ym1/1HqhgTTZ2iiALOctAfOwLla5W8BOvApAyx2DC4RSNSJ8A8z81ANmmbkt8w2l Rs9g51V95S7pm0lcUUF6keSvaJmIKL8+MrD3mrVitBzcI5wiW0KS46UiejOr2Hgk+wqa 1auBhgQ5aAnKROvgp8n0RyKA0bg3kDyJO/mbk5sZPDKvs3Bq/gu1c92RynPevAQHV60Q AQBFNTEeXht4cU3CriaiEqFOPs+RliV4koglw3poCN0zL9vIdQCAu4/V7FTQUILdCM0G ixvg==
- In-reply-to: <CAEk2Stn1-FF65dNzimH6FHbTKvWDd2Ng6RVVvFgc0eEKZ=urOQ@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <CABirCh-Ja3wnchdWV0H6AwRdMpdXJSNRn4KuMqVb4refa031mw@mail.gmail.com> <CAEk2Stn1-FF65dNzimH6FHbTKvWDd2Ng6RVVvFgc0eEKZ=urOQ@mail.gmail.com>
- Sender: email@example.com
On Fri, Mar 16, 2012 at 1:39 PM, Patrick Baggett
> On Fri, Mar 16, 2012 at 3:34 PM, Glenn Maynard <firstname.lastname@example.org> wrote:
>> On Fri, Mar 16, 2012 at 12:58 PM, Gregg Tavares (勤) <email@example.com>
>>> All the ones below here NEED to continue to allow NULL otherwise they
>>> will start throwing exceptions on context lost when all the createXXX
>>> functions start returning NULL.
>> I think that's a bit of a design error. If you call eg. createTexture
>> while the context is lost, it should probably return a WebGLTexture with the
>> invalidated flag already set, instead of returning null.
>> This has a few benefits. First, it eliminates the above problem;
>> functions don't need to be nullable when it's not the natural thing to do.
>> Second, it reduces the number of failure cases. Currently, if you do the
>> following, two different things might happen on context loss:
>> tex = ctx.createTexture();
>> ctx.bindTexture(ctx.TEXTURE_2D, tex);
>> If the context was lost before createTexture is called, tex is null.
>> However, the context might be lost *between* the createTexture and
>> bindTexture calls. If that happens, bindTexture receives a non-null texture
>> whose invalidated flag is set. These cases would be merged, so there's only
>> one error path to worry about.
>> Third, that things like this don't break in subtle, racy ways, because tex
>> is never null:
> Actually, I think that is a very valid point and definitely eliminates a lot
> of the strange, racy behavior that would otherwise be horrid to consider in
> a confident manner.
Glenn, thanks for raising this issue again. After giving this more
thought I am increasingly in favor of your proposal to return
invalidated WebGLObjects from the create* methods if the context is
lost, because of the unification of error handling behavior.
There are some things to consider. It will still be the case that some
get* methods will return null values in certain situations, in
particular when passed invalidated objects (per
http://www.khronos.org/registry/webgl/specs/latest/#5.14). Is this an
issue? If the goal is to eliminate the majority of null return values
under error conditions, that is a much larger change, and one which I
think should be done incrementally.
What are others' opinions on this potential change?
It would allow the spec to be tightened up in several places, as
nullable arguments could be changed to non-nullable. I don't think the
two changes (to the create* methods' semantics and to various methods'
nullable arguments) would have a significant compatibility impact on
existing WebGL content. Generally, the only reason that null arguments
would float in to these methods would be because of a context lost
event. Instead, invalidated objects would float in, leading to
INVALID_OPERATION errors. The TypeErrors that would be thrown because
of incoming null values would not occur.
The conformance tests would have to be updated, and previous versions
of the conformance suite would be broken, since there are some tests
that explicitly pass in null, and these would begin to throw
exceptions. However, I don't think real-world content would be broken.
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: