Re: [Public WebGL] Extension proposal: WEBGL_lose_context

["Gregg Tavares (wrk)" <gman@google.com>]

On Thu, Dec 16, 2010 at 11:24 AM, Kenneth Russell <kbr@google.com> wrote:

On Thu, Dec 16, 2010 at 12:54 AM, Gregg Tavares (wrk) <gman@google.com> wrote:
>
>
> On Wed, Dec 15, 2010 at 6:53 PM, Adrienne Walker <enne@google.com> wrote:
>>
>> El día 15 de diciembre de 2010 15:59, Gregg Tavares (wrk)
>> <gman@google.com> escribió:
>> > Here's the other problem I have with this extension.
>> > #1) For a _javascript_ app to be able to test they handle lost context
>> >    as pointed out, they can use _javascript_ for this
>> > #2) To be able to write lost context conformance tests
>> > #3) To test the browser's handing of lost context.
>> > The problem with but #2 and #3 is that this extension WILL NOT ACHIEVE
>> > EITHER OF THOSE GOALS.
>>
>> Failing to test absolutely everything does not imply a failure to test
>> anything.  Again, why are you arguing so strongly against increased
>> test coverage?
>
> I'm not arguing against increased test coverage. I'm arguing against an
> extension that will not actually provide any actual test coverage.
> The only way you can really test your actual implementation is to wrap all
> calls to OpenGL (not webgl) and then at some number of calls, start ignoring
> the calls and returning lost context from eglSwapBuffers or eglMakeCurrent
> The extension proposed doesn't do this. It will test almost zero paths
> through an actual WebGL implementation.

This statement is incorrect. In WebKit's WebGL implementation it will
test paths through code common to all WebKit ports (the
WebGLRenderingContext class in particular) and at least verify the
context lost checks at the beginning of those functions, as well as
the delivery of context lost and restored events. It's true that the
extension won't test loss of context in the middle of these functions,
but it will still verify a useful portion of the WebGL implementation.

I don't see this statement as incorrect. The WebGL implementions will likely be written effectively like this

WebGLContext::someWebGLFunction() {

   if (contexIsLost) 

     return;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

   code;

};

The proposed extension will skip all that code. Hence my assertion "The extension proposed doesn't do this. It will test almost zero paths through an actual WebGL implementation" is true. Most of the code in implementations will be skipped.

 

-Ken

>> I'd love to hear any suggestions you have for testing the cases that
>> you bring up in an automated fashion.  It's frustrating that the only
>> way so far that we've had to make code that uses glGet more robust was
>> to have you spend your time performing code inspection at potential
>> failure sites.
>>
>> -Adrienne
>
>