Trying to get a handle on WebGL context lost

simple example where I simulate context lost. Camera stops working and then when you hit play again you get Uniform buffer error.

In the docs it reports that Babylon handles this by default, is there anything else I need to do?

I’m getting a some uniform buffer and unable to create texture errors from clients (all platforms I think) which makes me think it’s caused by the context being lost. I will do some more research, but in the meantime I would like to know what the default is and should be for this playground.


You should call restoreContext to simulate a restore:

However, it still does not work. You should create an issue in the github repo about this.



Thank you!
I’m assuming the new full release of Babylon is not that close, unless you can tell me otherwise.
I took a look at your PR and it’s a bunch of files… would you say it’s doable for me to make the same fix into 4.1 or is that not advisable?
I’m hesitant to go to a preview version because I’m in full production mode…

Yes, we are still a number of months before the next release.

No, I don’t think it’s advisable, there were quite some changes and it would be difficult to back report them to 4.2 (and even more to 4.1).

1 Like

to be fair the preview of 5 should still be better than 4.1 :slight_smile:

Yeah I might try it out, I just have no context about how problem free it is in general.

This is the same as a stable as our build process is checking quite a lot of cases. In general release is an amazing time for communication for us and ensure all new features are done. So as long as you do not rely on innprogress new greatness you should be alll safe

1 Like

I got around to upgrading to 5.0 alpha 30, and I’m not quite sure if I need to do anything else, but simulating a context lost is still fatal. Also the originally posted playground is not working, so @Evgeni_Popov can you show me how you simulated this for your PR?

btw, so far my performance tests point toward a -10% performance compared to 4.1, but my tests are probably less accurate than yours.

I am really worried about the perf issue. Do you have a playground repo for it ? I would really like the version to be faster and not slower :frowning:

I ll let @Evgeni_Popov check the context lost issue

But @mise you need to call to restore context in order to simulate the behavior:

If it is only a pure loss there is nothing possible to do.

Also just double checked with @Deltakosh and we should be about 5% average faster in 5.0 so the repro would help narrowing what is happening

That does work for me:

Note that you have to simulate the context restore too.

[…] Ah, @sebavan already answered!

ah ok, so that was a mistake in my first post as well…
to be clear: do you have to do anything to restore when a natural context lost occures?

@sebavan I will get back to you in a PM about the performance later

Normally not, except if you create some webgl resources yourself that would not be tracked by the engine.

1 Like

I can now successfully simulate a context lost and restore in the middle of all kinds of animaitons/mesh creations etc. without getting any exceptions when handling it like this:

onWebglContextLost.add(() => pauseGameLoop(true));
onWebglContextRestored.add(() => pauseGameLoop(false));

However, when the context is lost in the wild I still get a report of the context being lost and not restored. Sometimes followed by an exception ‘cannot create uniform buffer/texture’.

One hypothesis is that the simualteContextLost is called in javascript, and thus not in the middle of a render loop, while in the wild it can happen at any point in code execution.
Unfortunately I haven’t encoutered or cannot simulate the natural context lost on my own device.

Do you think this is what’s happening and can you think of any way to test this, or prevent these exceptions and restore the context?

Do you call the code that simulates a context lost/restore inside of your program or outside (from the console of the browser for eg)? If the latter, I think it should be similar to a real lost/restore context event.

In any case, Babylon is notified through an event, so something which is handled in a specific javascript micro job, after the main js loop has been handled, so normally not inside the Babylon render loop.

Maybe you can try to postpone a bit the restoration of the game by doing setTimeout(() => { pauseGameLoop(false); }, 1000).

Note that in your pauseGameLoop(true) you should not do anything gfx related, as the context is lost.

  • from the console it works just as well
  • in the wild, the onContextRestoredObservable is never fired (context is not restored) and I do not call any babylon methods after it’s lost, so somehow there is still a texture or mesh created after it’s lost

it does seem to me like the simulation is not the same as the real thing. So far there have been 4 context lost events reported and 0 context restored. Could it be that the context just is not restorable? or is it always restorable? Not sure who is doing the restoring when restoreContext() is not simulated.