On Thu, Dec 16, 2010 at 10:26 PM, Kenneth Russell <firstname.lastname@example.org
> On Thu, Dec 16, 2010 at 8:55 AM, Alexey Marinichev
>> Chromium has code that detects if the context is lost, it does it by
>> checking if it can properly communicate with the GPU process.
>> process, so you cannot trigger the context recovery code.
>> If lost context extension is implemented as "kill the GPU process and
>> hope for the best", you'll be able to see if the browser will be able
>> to synthesize lost and recovered events properly.
>> I don't see a need in restoreContext function, the context should be
>> recreated automatically, that's what we are testing anyway.
> The way this extension is phrased, the context couldn't recover until
> the restoreContext function is called. In Chromium we could still kill
> the GPU process to implement loseContext (which would be very useful
> for increasing the testing coverage), and the GPU process could
> automatically restart; we would just need to add another gate which
> prevents the WebGLRenderingContext from thinking the context has
> restored until restoreContext() is called.
>> On Thu, Dec 16, 2010 at 11:54 AM, Gregg Tavares (wrk) <email@example.com
>>> On Wed, Dec 15, 2010 at 6:53 PM, Adrienne Walker <firstname.lastname@example.org
>>>> El día 15 de diciembre de 2010 15:59, Gregg Tavares (wrk)
>>>> > Here's the other problem I have with this extension.
>>>> > #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.
>>>> 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.