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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions



On Thu, Apr 22, 2010 at 8:40 PM, Vangelis Kokkevis <vangelis@google.com> wrote:
>
>
> On Thu, Apr 22, 2010 at 4:19 PM, Chris Marrin <cmarrin@apple.com> wrote:
>>
>> On Apr 22, 2010, at 4:02 PM, Gregg Tavares wrote:
>>
>> >
>> >
>> > On Thu, Apr 22, 2010 at 3:41 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> >
>> > On Apr 22, 2010, at 10:30 AM, Gregg Tavares wrote:
>> >
>> > > So I worked through some sample code using WebGLContextRestored and
>> > > convinced myself my fears were unfounded. Thank you for being patient with
>> > > me.
>> >
>> > Wait. I need context. Our current proposal has a WebGLContextRestorable
>> > event and a restore() method (replace restore with reset as needed). Is that
>> > your assumption, too?
>> >
>> >
>> > No need for restore() I think.
>> >
>> > What's needed is WebGLEventContextLost and WebGLEventContextRestored
>> > with the detail that WebGL will fail all calls until the
>> > WebGLEventContextRestored is delivered (ie, the function registered for it
>> > is called)
>> >
>> > In otherwords
>> >
>> > ctx = canvas.getContext("webgl");
>> > cavnas.addEventListener("webGLEventContextRestored", handleRestore);
>> >
>> > function handleRestore() {
>> >   // At this point ctx is usable and accesses the restored context, not
>> > the lost context.
>> > }
>> >
>> > That means that for example if I do this
>> >
>> > var textures[];
>> > for (var ii = 0; ii < 1000; ++ii) {
>> >   textures[ii] = ctx.createTexture();
>> > }
>> >
>> > And while that loop is running the OpenGL context is lost (say at ii =
>> > 123) and then restored (say at ii = 456) WebGL will still fail all calls
>> > after ii = 456 because the WebGLEventContextRestored has not yet been
>> > handled (JavaScript being synchronous)
>> >
>> > The other detail is that if no handler is registered then WebGL will
>> > fail forever after a lost context.
>>
>> Hey! You Google guys need to get your stories straight. Ken thinks we
>> should have the restore() function :-)
>>
>> I don't have a strong feeling either way. But it does feel odd that, if
>> you forget to setup an event handler, there will be no way to restore the
>> context. Of course that's a bug, but it does require you to handle events.
>> Maybe that's not a big deal.
>
> I don't think that what Gregg described implies that you need to register an
> event handler for ContextRestored to get the context restored.  If don't
> register the handler the context will be restored anyway. The trick is that
> the context won't be restored in the middle of your code's execution. It
> will happen synchronously, after your code relinquishes control (say you're
> done with the calls for the frame).

Oh boy, I'm not a big fan of the implicit restore.  Is there ever a
case where it is helpful to implicitly restore the context?  Maybe if
the context is lost and restored even before the app initializes any
of its GL resources?  That's all I can think of.

I'm in favor of requiring the app to affirmatively do something in
order to restore a lost context.

-T

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