[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Lost Context
On Wed, Feb 24, 2010 at 2:32 PM, Chris Marrin <email@example.com> wrote:
> On Feb 24, 2010, at 2:09 PM, Kenneth Russell wrote:
>> On Wed, Feb 24, 2010 at 10:27 AM, Gregg Tavares <firstname.lastname@example.org> wrote:
>>> Yet another lost context issue...
>>> How about adding a new error CONTEXT_LOST that gl.getError returns on all
>>> commands once the context is lost?
>>> Here's the issue that I think needs solving.
>>> You create a WebGL program that loads stuff asynchronously (like many of the
>>> current WebGL demos), while loading you lose the context (user sleeps the
>>> device, etc...), on recovery if the GL calls don't give CONTEXT_LOST than it
>>> doesn't seem like the initialization code will be able to distinguish
>>> between real failure "ie, this app can't run on this device" and lost
>>> context "ie, I need to start initialization over".
>> I agree that an indicator is needed. We have been discussing adding a
>> "context lost" extension to desktop OpenGL with a few vendors in
>> preparation for an ARB proposal, and some sort of indication that the
>> context has been lost is needed. The thinking was to make it a
>> glGetInteger query or similar, to avoid needing to call glGetError()
>> to determine that the context has been lost.
>> There are concerns with adding a new enum which isn't present in
>> either OpenGL ES or desktop OpenGL yet. If we do add an enum then we
>> should register it in the extension registry to avoid the possibility
>> of collision in the future.
>> Alternatively, we could add a function like "boolean isContextLost()"
>> or "boolean isContextValid()" to the context itself. This has the
>> disadvantage of introducing another type of error check that may need
>> to be queried by applications.
>> On the whole I would rather wait to see what form the planned desktop
>> GL extension takes before making a decision on the WebGL API. For the
>> time being we can use the asynchronous "context lost" event, and
>> perhaps synthesize INVALID_OPERATION in the case you describe. I think
>> it will still be possible to write apps that handle the lost context
>> case. Upon receiving a context lost event the app should completely
>> reset itself, so if it received GL errors during the last few calls
>> before it received the event, that shouldn't matter.
> I agree with the idea of returning this as a specific error. But I sure hope we can find a way to make it clear that this is a context-lost error. I'd hate to add a function for this, for the reasons you mention. And I'd hate to return INVALID_OPERATION because that will give the author no clue as to what happened. If OpenGL is working on this, might they have an idea of what the error code will be so we can use it? If not, is there any range of "vendor defined" error codes in OpenGL?
I've talked with NVIDIA, who are shepherding the extension through
(Greg Roth specifically), and it sounds like it will take form within
a couple of weeks. I think we should simply defer this discussion
> You are currently subscribe to email@example.com.
> To unsubscribe, send an email to firstname.lastname@example.org with
> the following command in the body of your email:
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: