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

Re: [Public WebGL] Extension proposal: WEBGL_lose_context

On Wed, Dec 8, 2010 at 10:43 AM, Gregg Tavares (wrk) <gman@google.com> wrote:
> On Wed, Dec 8, 2010 at 8:49 AM, Adrienne Walker <enne@google.com> wrote:
>> El día 7 de diciembre de 2010 18:21, Gregg Tavares (wrk)
>> <gman@google.com> escribió:
>> >
>> > On Tue, Dec 7, 2010 at 3:31 PM, Adrienne Walker <enne@google.com> wrote:
>> >>
>> >> I considered that approach, but an extension makes it possible to have
>> >> a conformance test that verifies that the WebGL context returns the
>> >> correct values during a lost context and correctly invalidates old
>> >> resources after the context is restored.  You can't test the WebGL
>> >> implementation itself with a pure Javascript implementation.
>> >
>> > I don't see how that's true. For all you know it only returns the
>> > correct
>> > values when the extension is enabled.
>> I don't understand what you're getting at here.  Arguably, an
>> implementation could detect and fake the correct results on *any*
>> conformance test.  Are you trying to argue about the value of
>> conformance tests in general?
> The point I'm getting at is no other API in any language I know of has
> testing extensions.
> Is there an API for XHR that tests of the network gets disconnected?
> Is there an API for reading a file that tests if the disc gets corrupted?
> Is there an API that tests canvas works display bit depth changes?
> Is there an API in EGL that tests losing the context?
>> >> It's just a bonus that app developers could also use this extension
>> >> for their own testing without having to write their own (hopefully
>> >> correct) version.
>> >
>> > They're going to have to write code to use the extension. They're going
>> > to
>> > have to write code to check losing the context at various places in
>> > their
>> > code. So do see how this is much of a win.
>> The difference between writing a Javascript wrapper and using this
>> extension is probably on the order of hundreds of lines of code.
>> Using this extension is about four additional lines of code.  (Check
>> extension, enable extension, lose context, restore context.) It's
>> something that's easily explained and posted in a snippit.  The
>> Javascript wrapper has to return special values from certain
>> functions, it has to early out of all functions, it has to invalidate
>> resources that are no longer in use, it has to check if those
>> resources are being reused after the context is being restored and
>> throw errors.  None of these things are hard, but there are a lot of
>> details.
> We have an example of a wrapper. It is exceedingly easy to write. Adding
> code to return LOST_CONTEXT once and ignore all other calls is dead simple.
> Adding the few special cases is trivial as well. This is literally a 10-20
> minute exercise.  In fact, you or I could write it and this problem would be
> solved, cross platform, and not need any agreement or discussion related to
> any specs. We can on the khronos site. Done.

I doubt it's that simple. As Adrienne points out, if a WebGLTexture
object is created and then the context is lost, it has to be illegal
to use that WebGLTexture object after the context is restored. This
will either require the JS "lost context" wrapper to itself wrap all
WebGL objects, or add an expando property on each one and check it in
many APIs. Additionally, it will probably have to mirror the OpenGL
state so that it can zero everything out on the underlying
WebGLRenderingContext during restoration.

> There is no reason to clutter the API or extension registry
> with superfluous testing API for which there is no analog anywhere else.

This extension would provide significant benefits for both content
authors as well as WebGL implementors. It would help authors make
their content more robust by allowing them to test losing the context
either deterministically or randomly and make sure their apps recover.
It would help WebGL implementors by exercising the real lost context
code path, which otherwise is difficult to test. Just because the
other APIs you mentioned don't have testing mechanisms (and perhaps if
XHR did then many more web sites would work better in the face of
unreliable network connections) doesn't mean that this one shouldn't
be added. I think we should document this extension, if not in the
WEBGL_ namespace then at least in WEBKIT_ or CHROMIUM_.


>> I worry that most folks writing WebGL apps won't bother making them
>> robust under lost contexts either because they don't know or because
>> they think it's a lot of work.  The more conscientious developers will
>> surely do it regardless, but I suspect that most will probably not.
>> From my point of view, making it easier for developers to test this
>> and make more robust apps can only be a good thing.
>> -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: