[Public WebGL] getSupportedExtensions + context loss

Kenneth Russell [email protected]
Thu Apr 26 16:52:47 PDT 2012

On Fri, Apr 6, 2012 at 3:20 PM, Glenn Maynard <[email protected]> wrote:
> getSupportedExtensions says "Any string in this list, when passed to
> getExtension must return a valid object."
> Currently, this conflicts normatively with what actually happens: if the
> context is lost, null is returned.  A quick fix is to move this to
> getExtension (it's defining getExtension requirements, so it should be
> within that function's definition), and say "A valid object must be returned
> if (and only if) name is included in the return value of
> getSupportedExtensions."

Thanks for the suggestion. I agree that getExtension should define its
own behavior, rather than having getSupportedExtensions define it.
I've adjusted the wording for both based on your suggestion.

>  (This doesn't really touch on the fact that
> getSupportedExtensions can change after a context loss and restoration.  I'm
> not sure if anything normative is needed about that...)

Let's deal with this issue separately. There are more complications
related to extensions and context loss. In particular, consider the
situation where an extension object is fetched from a context, and
then the context is lost and restored. If the restored context still
supports the extension, can the old extension object still be used? Or
does it need to be re-fetched? What happens if a previously-fetched
extension object is no longer supported?

One suggestion to solve these issues uniformly would be to invalidate
all extension objects upon context loss, and require them to be
re-fetched once the context is restored.

> Aside from this, I think a better fix would be for both getExtension and
> getSupportedExtensions to ignore context loss.  getSupportedExtensions
> always returns the set of supported extensions for the last-created context,
> and getExtension always returns extension objects (even for lost contexts).
> That eliminates some possible context-loss-related bugs.  For example:
> if(ctx.getSupportedExtensions.indexOf("extension") != -1) {
>     var ext = ctx.getExtension("extension");
>     ext.func();
> }
> This isn't a common pattern now, but if the "profile extensions" ever gets
> any traction--I wish that would get some attention--then it would be useful.

Per other recent lost context discussions, I haven't adjusted these
semantics. There are many other APIs that can return null, and where
no other value than null can reasonably be returned while the context
is lost.

> (Later, for the "context initially lost" case, I think we should have the
> initially-lost case define a strict, narrow set of functions that you're
> allowed to use in that state.  That set might be empty--you can't call any
> context methods whatsoever, and the only thing you can do is wait for
> context restoration.  That way, we don't need to define what functions do in
> that very exceptional case.  After all, the UA might not even have a real
> WebGL implementation in that state, or have any GPU or drawing API active,
> so there's nothing meaningful any WebGL function could do.)

The only entry points that have any non-trivial behavior while the
context is lost is the small set with explicit context lost handling (
http://www.khronos.org/registry/webgl/specs/latest/#5.14 ). It doesn't
seem to me that another list of methods that can be called will be
necessary, but experience will show once asynchronous context creation
is added.


You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list