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?
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.
Thanks for jumping on this! A couple of last questions!
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?
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?
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.
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.
