[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 2:50 PM, Adrienne Walker <email@example.com>
El día 8 de diciembre de 2010 18:58, Gregg Tavares (wrk)
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.
For an app developer, i see no difference between using this code or
> 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.
using the proposed extension.
I'm having a hard time understanding why you're arguing so strongly
> I don't see that difference as enough justification to clutter the register
> with an extension for this.
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
#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.
I will happily take suggestions on other methods to test this behavior
either in general or in WebKit specifically.