1144115 - WEBGL context loss simulation call restoreExtension() does not function.

Status: RESOLVED INVALID

(Core :: Graphics: CanvasWebGL, task, P2)

Description

[Jukka Jylänki]

Attachment: webgl_restore_context.html

The WEBGL_lose_context extension exposes functions loseContext() and restoreContext() to allow manually simulating WebGL context loss and restore events: https://www.khronos.org/registry/webgl/extensions/WEBGL_lose_context/

However it looks like while the function loseContext() works ok, attempting to manually restore the context via a call to restoreContext() gives an INVALID_OPERATION and never succeeds. See the attached file for a unit test.

STR:
1. Run attached webgl_restore_context.html
2. See the page console

Observed: The page console prints

     GL error after 37442
     context lost!
     Context was not restored by call to restoreContext()!

Expected: The page console should print

     context lost!
     context restored!

Comment 1

[Botond Ballo [:botond]]

CC'ing Jeff and Dan.

Comment 2

[Kelsey Gilbert [:jgilbert]]

This conditional is to blame:
hg.mozilla.org/mozilla-central/annotate/09f6642f7d24/dom/canvas/WebGLContextGL.cpp#l3645

As coded, if you don't call preventDefault() on the context loss event, we disallow the event from being restored.
The question here is whether loseContext() should ignore this requirement.

Since the goal of loseContext() is to emulate an actual context loss event, it should allow for testing that a context is not restorable if it did not call preventDefault(). Since we want to be able to test this, not calling preventDefault() (as in your attachment here) means that a context may never be restored.

Please reopen if you disagree and would like me to confer with the working group.

Comment 3

[Jukka Jylänki]

Oh, I see - yeah, that is accurate. I was going back and forth with https://www.khronos.org/registry/webgl/extensions/WEBGL_lose_context/ as my only documentation, which does not describe this behavior. I think I am ok with the current behavior, however, tinkering with this more, I think the WEBGL_lose_context specification should document these behaviors explicitly:

1) If the developer does not register a handler to "webglcontextlost" at all, after calling .loseContext(), it is not possible to call .restoreContext() to restore the context. Like you mention, to be able to restore the context, one should have the line

  canvas.addEventListener("webglcontextlost", function(e) { e.preventDefault(); }, false);

before calling .loseContext(). That is not documented behavior by WEBGL_lose_context, so I think that requirement should be explicitly added to the spec.

2) I see it is not possible to immediately call .restoreContext() in the event callback webglcontextlost, even if e.preventDefault(); was called in that event callback previously. Such a call always fails. This should probably be documented in the spec as "you may not attempt to restore the context in a webglcontextlost event handler".

3) I see the effects of .restoreContext() are not synchronously observable. That is, calling

    context.restoreContext();
    if (context.isContextLost()) console.error('Context was not restored by call to restoreContext()!');


after webglcontextlost event has fired does print an error. I think the spec should document this by saying "The effects of .restoreContext() are not synchronously observable." or similar.

Jeff, do you think 1)-3) should all be intentional as per spec, or something Firefox should change? I am fine with all of the above being features, however I would like the WEBGL_lose_context spec to be explicit in documenting these.

Comment 4

[Kelsey Gilbert [:jgilbert]]

(In reply to Jukka Jylänki from comment #3)
> Oh, I see - yeah, that is accurate. I was going back and forth with
> https://www.khronos.org/registry/webgl/extensions/WEBGL_lose_context/ as my
> only documentation, which does not describe this behavior. I think I am ok
> with the current behavior, however, tinkering with this more, I think the
> WEBGL_lose_context specification should document these behaviors explicitly:
> 
> 1) If the developer does not register a handler to "webglcontextlost" at
> all, after calling .loseContext(), it is not possible to call
> .restoreContext() to restore the context. Like you mention, to be able to
> restore the context, one should have the line
> 
>   canvas.addEventListener("webglcontextlost", function(e) {
> e.preventDefault(); }, false);
> 
> before calling .loseContext(). That is not documented behavior by
> WEBGL_lose_context, so I think that requirement should be explicitly added
> to the spec.

Yeah, this could be clarified. It's not really clear from the spec, only from the intent of the spec.

> 
> 2) I see it is not possible to immediately call .restoreContext() in the
> event callback webglcontextlost, even if e.preventDefault(); was called in
> that event callback previously. Such a call always fails. This should
> probably be documented in the spec as "you may not attempt to restore the
> context in a webglcontextlost event handler".

Yes, this needs clarification.

> 
> 3) I see the effects of .restoreContext() are not synchronously observable.
> That is, calling
> 
>     context.restoreContext();
>     if (context.isContextLost()) console.error('Context was not restored by
> call to restoreContext()!');
> 
> 
> after webglcontextlost event has fired does print an error. I think the spec
> should document this by saying "The effects of .restoreContext() are not
> synchronously observable." or similar.

Yes, this needs clarification. (though we shouldn't spec the effects, but rather the functionality)

> 
> Jeff, do you think 1)-3) should all be intentional as per spec, or something
> Firefox should change? I am fine with all of the above being features,
> however I would like the WEBGL_lose_context spec to be explicit in
> documenting these.

I believe these are correct for our implementation. We should submit pull requests to update the specs with clarifications.

Comment 5

[Kelsey Gilbert [:jgilbert]]

https://github.com/KhronosGroup/WebGL/pull/3018

Comment 6

[Kelsey Gilbert [:jgilbert]]

I think we're done here. (INVALID=NOTABUG, at least now)