Hello,
Has anyone encountered the WebGL Context Lost on M4 chip devices? I have an app that has been deployed on web as well as on AppStore using ionic Capacitor. It works just fine on all other iPads apart from the ones with M4 chips.
I have also noticed that NONE of the ThreeJS web apps work on my Safari (MacBook Pro 16" M3 Max), including @donmccurdy 's GltfViewer. Same issue - ThreeJS Context Lost. As soon as I drop any 3d model, it just crashes.
I have debugged my app and I know that the context is lost on WebGLRenderer creation. I am at my wits end, as this feels completely out of my hands.
Is there anything I am missing or need to take care of for my apps to work on these devices?
Any help is welcome.
I can contribute, that I don’t have any issues of that kind with a MacBook Pro. 16" M4 Max, neither with my own Three.js apps, nor “@donmccurdy 's GltfViewer”. And that goes for both Safari (18.3) and Firefox (135.0). Current OS is Sequoia 15.3.1.
P.S.: does the console give any indication why apps are failing?
==> Safari / Developer Menu / JavaScript Console
Upon further testing on my MacBook Pro 16" M3 Max, what I have concluded that in any safari session, once the gltf context is lost in ony of the tabs, no other example works. If I start a new session, it works just fine. But if I am just closing the tabs and opening new ones, it’s the same. I have to quit Safari to get it working again.
Now coming to the crucial part of that first GLTF context loss, it’s happening in my app. You can test it here -
I am using vanilla js version of the MeshRefractionMaterial shader from react-three/drei. Seems like it’s an issue arising from three-mesh-bvh on these devices. I will log an issue there.
@gkjohnson Can you suggest why this is happening? I am creating a standalone project on codesandbox to replicate the issue. Your diamond example doesn’t have this issue, but the same code fails when applying the material to more than one mesh or more than one instance of the material (either via cloning or creating with new).
@gkjohnson Can you suggest why this is happening?
This sounds like a browser / device regression. Browser WebGL shader middleware and graphics hardware are complicated and it’s incredibly difficult to understand what your shader code is transformed into by the browser by the time it reaches any native graphics driver that may cause a crash. Naturally more complex shaders may be more sensitive to these issues. You can check the refraction demo at the official three-mesh-bvh repo to see if it’s also causing issues and if it’s not then there may be something specific to the drei implementation causing issues.
But even then I have seen many cases where perfectly valid shader code can cause WebGL contexts to crash or behave incorrectly on variety of different devices. Tracking these issues down amounts to guessing and checking which incantation of syntax may be causing a problem even though it’s correct. And fixing it may break another device that a workaround has been added for.
Ultimately this is something that should be reported to and fixed by the browser vendor or driver developer.
I have created a standalone codesandbox that showcases the issue here -
https://codesandbox.io/p/sandbox/cocky-taussig-c78rmh
If you try in Chrome, it works for both your diamond example, as well as my eyewear example. In Safari, it only works for your single diamond, but not for my eyewear that has two zones of diamonds. Single bvh is generated for each diamondzone.