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

Re: [Public WebGL] Extension proposal: WEBGL_lose_context



On Thu, Dec 9, 2010 at 3:39 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
>
>
> On Thu, Dec 9, 2010 at 2:50 PM, Adrienne Walker <enne@google.com> wrote:
>>
>> El día 8 de diciembre de 2010 18:58, Gregg Tavares (wrk)
>> <gman@google.com> escribió:
>> > So I implemented this in JavaScript.
>>
>> Great! I'm sure that'll be quite useful for app developers, especially
>> once https://bugs.webkit.org/show_bug.cgi?id=36512 gets fixed.
>>
>> > To use that extension in any meaningful way means either littering your
>> > code
>> > with calls to loseContext and restoreContext or wrapping the entire
>> > context
>> > and calling it on a call count or randomly.
>>
>> For an app developer, i see no difference between using this code or
>> using the proposed extension.
>>
>> > I don't see that difference as enough justification to clutter the
>> > register
>> > with an extension for this.
>>
>> I'm having a hard time understanding why you're arguing so strongly
>> against extra testing coverage.
>
> Tradition: Like I pointed out, I see no precedent. Name another common API
> that has failure testing functions.
>
>>
>> Even code that is exceedingly easy to write still has bugs.  For
>> example, in the script you just posted, you may want to fix the bugs
>> where the "is functions" and "functions that return null" don't
>> actually override the wrapper version because you need to add
>> ".length" in the for loop.  Also, getBufferParameter,
>> getContextAttributes, and getParameter should all return null under a
>> lost context instead of undefined.
>
> Thanks for the bug report. Fixes checked in.
>
>>
>> If your code has these bugs, then what about the currently untested
>> WebGL implementation side of things? In my opinion, a documented WebGL
>> extension seemed like the most reasonable way to test this logic,
>> regardless of what prefix the extension has.
>
> The argument against is mostly a matter of style and precedent. As I pointed
> out, I know of no other common APIs that have "simulate failure" APIs. I
> named 4 examples. There is no "simulate XHR losing a network connection"
> API. There is no API for  "test file reading when device fails" like a user
> disconnecting a usb drive or a sd card. This is no "similate lost context in
> EGL" API.
> I think there are several issues here.
> #1) Let app developers test their apps handle lost context
>
> JavaScript can already provide this solution. In Chrome they can also just
> go to the task manager and kill the GPU process.
>
> #2) Let browsers check their own lost context implementations.
>
> This seems browser specific. Not the place for an official spec.
>
> #3) Let Khronos have a conformance test for WebGL implementations that they
> handle lost context correctly
>
> This might be the best argument for this extension. The problem IMO is
> simulating lost context is not the same as actually getting a lost context.
> One is controlled, the other is uncontrolled. Because of that the extension
> would only really handle #1, not #2 or #3.

First, thanks for writing your JavaScript wrapper for testing lost
context delivery.

Having this extension improves the testability of the browser's lost
context implementation. It would even add value to your wrapper by
exercising the real code paths the WebGL implementation would use.

I would like to add this extension to the registry and support it in
Chromium. Vlad, Benoit, is there any interest from Mozilla in
supporting this extension to exercise your implementation? Tim, how
about Opera? If there isn't interest from any other vendor then we can
just use the CHROMIUM_ prefix, but I think it would be useful more
generally.

-Ken

>> I will happily take suggestions on other methods to test this behavior
>> either in general or in WebKit specifically.
>>
>> Regards,
>> -Adrienne
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: