Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
WEBGL_lose_context.restoreContext is used for restoring context
See original GitHub issueI’m fairly certain that (WEBGL_lose_context).restoreContext() is not intended to be used to recover from a general loss of context situation, it rather seems to be intended for recovering from (WEBGL_lose_context).loseContext() for debugging purposes.
See the specification and the following discussion on StackOverflow.
This is probably directly related to #7206, where it can be seen that the system can’t actually handle real context loss, just a simulated one.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:15 (8 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
This is still an issue in the current master branch and should not be closed.
I didn’t get around to commenting on #7206 before it was closed by stalebot, but we still have that issue in 6.2.0. Currently, we restart the application in the event of a WebGL context loss to get around the sprites not rendering.
In our testing of recovery methods, we were able to get things to recover and render properly after a WebGL context loss by listening for a context loss and then recreating all of the graphics objects and sprites. We ended up not using this recover method this as it would eventually fail if there were multiple context losses in the same session. In the event of successive context losses pretty much everything would stop rendering regardless of when or how it was created.
I think our context loss/restore really needs some help.