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

Re: [Public WebGL] Extension proposal: WEBGL_lose_context

On Thu, Dec 16, 2010 at 12:14 PM, Alexey Marinichev <amarinichev@google.com> wrote:
Postponing recreating the context until restoreContext is called is
adding extra logic in the implementation that doesn't really add
anything useful.  I'd vote for removing it and simply have loseContext
simulate exactly what happens if WebGL implementation notices that the
context was lost.

The implementation is allowed to keep the context lost for as long as it wants. For example
if there are 2 tabs with webgl apps and the system runs out of vram, an implementation
could issue lost context to both apps, then only restore it to the top tab.

The other tab's app would need to respect that it doesn't get the context back for a long time.
(until that tab comes to the front)

On Thu, Dec 16, 2010 at 10:26 PM, Kenneth Russell <kbr@google.com> wrote:
> On Thu, Dec 16, 2010 at 8:55 AM, Alexey Marinichev
> <amarinichev@google.com> wrote:
>> Chromium has code that detects if the context is lost, it does it by
>> checking if it can properly communicate with the GPU process.
>> _javascript_ code cannot affect the communication channel to the GPU
>> 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.
> -Ken
>> On Thu, Dec 16, 2010 at 11: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
>>>> 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.
>>>> -Adrienne