Recovering texture loads on lost context

Under certain conditions, updating textures results in a context lost event. If a texture load happens during or immediately after this event, the texture will fail to load with Unable to create texture but the error handler on that texture never fires.

If you then check the engine._gl.isContextLost() status, it will sometimes be true or sometimes be false.

What I think is happening is that Babylon is recovering from the loss of context but does not attempt to reclaim any pending texture loads. You can see the issue demonstrated here:

My question is, should Babylon keep track of operations that failed because the context was lost, and on recovery attempt to continue the previous track?

So far our philosophy was that it is up to the developer to catch the issues and apply the required counter measures.

babylonjs will handle the recovery of everything which was loaded successfully

But one thing that you’ll notice is the “ERRORED OUT” handler never fires. This makes it difficult to recover and see that the issue was in the texture load.

I’ll check that so :wink:

1 Like

PR sent! will be in next nightly in a hour or so :slight_smile:

Nice! Can you share a link? I’m curious what the fix was :slight_smile:

sure thing: Fix texture error handling when context is lost · BabylonJS/Babylon.js@45c15a9 (


Thanks for jumping on this! A couple of last questions!

  1. The machine we’re seeing this on is running multiple tabs with texture updates that can happen simultaneously. However, there is plenty of GPU power left over (the machine has a Tesla GPU with 16GB) and we don’t seem to be taxing it at all. So what actually causes context loss? Is there some kind of a finite number of textures that can be uploaded to the GPU at the same time?
  2. Is there a cost to recovering from context lost? Like does it present any kind of memory leak or can we just operate as normal as long as we catch the event and retry the textures?
  1. So the GPU process is shared and I do not think it can use all your GPU memory and it has a certain limit s in terms of canvases numbers.

  2. It is taxing a bit of perfs cause it needs to recreate everything but should not leak.


Ok, still more questions :slight_smile:

Does this same issue happen when using Babylon Native? If we were running two instances of a native Babylon app would one of them possibly lose context in this same way?

I do not think we have a notion of context lost in native (aking for a friend @bghgary ) But you might still crash the gpu if you are asking too much from it.

1 Like

So I assume the same GPU crash/context lost events will fire for recovery in those cases?

Babylon Native needs to handle this, but so far, we haven’t tried to figure out how this will work. Ideally, whatever events that are available to Babylon.js should also work in Babylon Native. We just haven’t gotten that far yet. :slight_smile:


Thanks for all the help here. One last question, I swear! When do you think the next alpha release is coming?

I ll do one today or tomorrow if you need one ?

1 Like

Yes, but only if it won’t break anything :slight_smile:

It SHOULD not :slight_smile: