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.