For the last week or two we’ve been getting reports of iOS issues, with the context being lost suddenly, and then being unable to recover. I was able to reproduce it a few times on ios 14.0, WebGL 1 and 2 on BabylonJS 4.1. I can’t say for sure it is related, but we didn’t get these reports previously, and I’ve certainly never noticed it myself.
I’ve seen after this error occurs, the context eventually restores (which I suspected after reviewing the ThinEngine source), but our scene is unusable because all of the textures etc. come from another context. Is there some way we’re supposed to be handling these gracefully and the loss of context is a standard occurrence now? Is there something we’re doing wrong that is causing this to happen, or is this just something in ios 14.0 and we should wait for ios 14.2 or perhaps a move to Babylon 4.2 when that releases?
This is sad but safari is a pile of crappy shit.
That being said, the engine will raise an event for you to recreate your own assets with onContextRestoredObservable and onContextLostObservable
Updates: I’ve found that this issue only occurs using WebGL1, and goes away if you enable WebGL2. It also seems triggered by scrolling the underlying page or rotating the screen.
Eventually the context does restore, but my app becomes unusable as I cannot compile any shaders - none of the extensions such as derivatives work on the restored context.
It’s not really my choice - I can tell customer support to tell our customers to turn that on, but it being under the Experimental Features section of the settings makes that a bit hard to swallow.
I’m wondering if there’s something I can do to prevent it, and I’m still unsure how to recover from it when it does occur.
Ok gotcha
would you like then to try to mimic as much as you can what you use in the playground? I will try to simulate context lost then using webgl1 to see if we are missing something
I’ve managed to fix this issue, but updating here in case it is relevant to the Babylon internals or future devs dealing with the same issue.
The issue here is passing a uniform with the wrong type, or changing the type between updates, and then using that uniform value in the sin() function in GLSL code. For us, this was using Number.isInteger() to determine whether to call setInt or setFloat for some runtime/config driven uniform values. If you’ve used this in the sin function with multiple data types, the context will be lost when engine.resize() is called (likely in your window resize event handler).
TL;DR don’t try to infer the type at runtime, you need to keep track of this if you have any system for generically handling uniform values.
We’ve seen this as well for users who have upgraded to Safari 14.0. Right now we’re seeing the browser crash completely on Safari 14.0 on both iOS and desktop. The issue goes away (on some users) if we enable WebGL 2.0.
From the conversations you’re seeing here, do you think there’s a fix that is possible in Babylon, or do we just have to wait for Safari to update with a patch? We’re weighing whether or not to just disable 3D for these users.
@Alex_B Have you checked your shaders etc. for improperly passed uniform values? You might see a WebGL warning logged in the console if it is occurring.
Over on the ThreeJS issues page, they claim to have been able to reproduce the issue without creating the WebGL instance. Just resizing canvas enough times causes the crash. They’ve logged a bug with Apple but I’m not seeing much activity on that ticket.
I am also seeing this issue… @Prodigal in your error log, do you still get the WebGL: INVALID_OPERATION: delete: object does not belong to this context errors even after fixing?
Just trying to determine what errors i should expect/not expect to see.
I don’t - after fixing my uniform issue, I can rotate the canvas (via switching between portrait / landscape) as frequently as I want and the context is never lost.
Perhaps the root cause of my issue is different than yours, but we’re using a lot of different functionality - PBRCustomShader, ShaderMaterial, CustomProceduralTexture, with animated uniforms, etc. and I was able to get it stable (after pulling my hair out for a week and a half).
Found it, surprisingly quickly. We use a custom shader with a 2nd UV channel. The material had data for a 2nd UV channel, but the mesh didnt have a 2nd UV channel on it… wowzers.
