Performance expectations vs web

[funkyfourier]

So I have tried the example from "Creating a scene", and encountered some performance issues. I have tried running the same example in browser to compare performance.

On iOS (both an iPhone 5S and iPhone8) the framerate seems to be smooth, except that it stutters a little bit every second or so. The Perf Monitor says about 60 for both JS and UI on both phones.

On Android the framerate so bad that no FPS counter or profiler is needed to tell that. I ran the example on a Nexus 6 and got roughly between 40 and 55 FPS for JS and 60 for UI. On the same Nexus, if I run the similar example in Chrome, it seems to run much smoother.

I have also run the "Animation Cloth" demo, and I get similar results. Much better framerate in the browsers, especially on Android.

What kind of performance can be expected when using Expo.GLView as opposed to webgl in a webview? I read somewhere that Expo.GLView somehow bypasses the javascript bridge, but I cannot see how that can be as it seems like the game loop is run from javascript.

Are there any possible solutions to this on the horizon?

[EvanBacon]

Performance is still actively improving all the time. A lot of the performance issues are related to all the computation that three.js is running. Pure GPU things are much faster in EXGL than in the WebView. A big reason that webview is faster right now is that it uses JIT and apple only allows this in a few cases. As of v25 of Expo GLSL 3 shaders became supported which made all EXGL projects much faster. We have a bunch of potential optimizations that we can create, it's just a matter of finding the time to do it :)

[funkyfourier]

Thanks for responding!

But... Is not the main bottleneck the javascript bridge? If one runs a game loop, for example, the bridge would have to be crossed 60 times each second.

Also, I had definitely the worst performance on Android, and there JIT is allowed...no?

[nikki93]

@funkyfourier no because the GL bindings happen not through the React Native JS bridge, they are directly bound with the JavaScriptCore C API (see https://github.com/expo/expo/blob/67aa7741171ee6b6e3df5700777ea29220626e82/cpp/UEXGL.cpp). The perf is (from my profiling a bit ago) mostly due to differences in like pure math in JS. We could theoretically enable JIT on Android JSC but I don't think we do right now. 🤔

[funkyfourier]

Thanks again for responses! I will be following this closely.

Could it be an idea to formulate a document with do's and dont's with regards to how to achieve optimal performance when using EXGL? Also explain where the boundaries and bottlenecks are, and how to work around them?

[Losses]

@nikki93 @EvanBacon I think the problem is more complex, we made a reproduction on snack, can we get a chance to solve the performance issue?

https://github.com/expo/expo/issues/12399

[Vardiak]

Is this issue still as bad as 3 years ago ? I'm considering ExpoGL for a game engine and performance is a concern.

[Losses]

Is this issue still as bad as 3 years ago ? I'm considering ExpoGL for a game engine and performance is a concern.

@Vardiak According to our research, ExpoGL’s performance is far worse than WebGL, and the official developers don't want to cost too much time on it. If you’re developing a game with JavaScript, ExpoGL is not an option as far as what I've seen.