Nope it is not common at least in Firefox which supports WebGL 2 correctly.
Could you repro in the playground ??? that said 3 214 572 indices is a LOT and with 220 meshes if you do not freeze anything it is probably bottlenecked on the CPU/JS side.
Also make sure hardware rendering is enabled. I think some other people had the problem in the past with Firefox and hardware rendering was disabled in some cases.
If you are CPU/JS bound, Chrome will almost always win since V8 is faster compared to Firefox (SpiderMonkey) and Safari (JavaScriptCore) in that order.
Hi All. Would like to revisit this. We are seeing very significant differences in framerate from Safari vs. Chrome (60fps on chrome vs 15fps on safari) (keep in mind my envionment for these benchmarks is MACOS Monterey) . The documentation on per-browser optimization is a little sparse. We are “assmbling” the asset in our app using multiple .glbs. Ive exported the whole lot as one .glb to test via the sandbox. Strangely that asset runs at almost identical framerates in the sandbox. So i doubt it has to do with the asset itself and more so our engine configuration and/or other things like post processing. We will continue to dig. Are there any specific features on BJS that are not very Safari friendly? Most of our benchmarking thus far has been on chrome and have been ignoring safari but we really cant continue to do that and will need to address this.
(screenshot is same asset, chrome vs safari (Driver: AppleGPU)
update: looks like image processing is causing huge hits to FPS on safari. We are trying the best we can to reduce draw-calls…etc. but this by far is the biggest contribution. I dont think simply removing image processing is going to be an option for us. here is a screenshot of our imagePP stack.
This thread is interesting because we’ve also experienced poor performance on Firefox. It’s reassuring that it’s potentially not our code / hardware… Sorry If I’m not contributing, I just thought I’d share our my mate’s and my experience.