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

Re: [Public WebGL] Extension proposal: WEBGL_lose_context

On Wed, Dec 8, 2010 at 8:49 AM, Adrienne Walker <enne@google.com> wrote:
El día 7 de diciembre de 2010 18:21, Gregg Tavares (wrk)
<gman@google.com> escribió:
> On Tue, Dec 7, 2010 at 3:31 PM, Adrienne Walker <enne@google.com> wrote:
>> I considered that approach, but an extension makes it possible to have
>> a conformance test that verifies that the WebGL context returns the
>> correct values during a lost context and correctly invalidates old
>> resources after the context is restored.  You can't test the WebGL
>> implementation itself with a pure _javascript_ implementation.
> I don't see how that's true. For all you know it only returns the correct
> values when the extension is enabled.

I don't understand what you're getting at here.  Arguably, an
implementation could detect and fake the correct results on *any*
conformance test.  Are you trying to argue about the value of
conformance tests in general?

The point I'm getting at is no other API in any language I know of has testing extensions.

Is there an API for XHR that tests of the network gets disconnected?
Is there an API for reading a file that tests if the disc gets corrupted?
Is there an API that tests canvas works display bit depth changes?
Is there an API in EGL that tests losing the context?

>> It's just a bonus that app developers could also use this extension
>> for their own testing without having to write their own (hopefully
>> correct) version.
> They're going to have to write code to use the extension. They're going to
> have to write code to check losing the context at various places in their
> code. So do see how this is much of a win.

The difference between writing a _javascript_ wrapper and using this
extension is probably on the order of hundreds of lines of code.
Using this extension is about four additional lines of code.  (Check
extension, enable extension, lose context, restore context.) It's
something that's easily explained and posted in a snippit.  The
_javascript_ wrapper has to return special values from certain
functions, it has to early out of all functions, it has to invalidate
resources that are no longer in use, it has to check if those
resources are being reused after the context is being restored and
throw errors.  None of these things are hard, but there are a lot of

We have an example of a wrapper. It is exceedingly easy to write. Adding code to return LOST_CONTEXT once and ignore all other calls is dead simple. Adding the few special cases is trivial as well. This is literally a 10-20 minute exercise.  In fact, you or I could write it and this problem would be solved, cross platform, and not need any agreement or discussion related to any specs. We can on the khronos site. Done.

There is no reason to clutter the API or extension registry with superfluous testing API for which there is no analog anywhere else.


I worry that most folks writing WebGL apps won't bother making them
robust under lost contexts either because they don't know or because
they think it's a lot of work.  The more conscientious developers will
surely do it regardless, but I suspect that most will probably not.
>From my point of view, making it easier for developers to test this
and make more robust apps can only be a good thing.