Is "expo-gl" the best choice for React Native support? [Question]

[gomes042]

Just asking, I know it's hard to find OpenGL ES renderer solutions for React Native and running away from WebViews on mobile is a good practice. But have there been tests using projects like bgfx or GCanvas for example?

Is there any problem nowadays with the expo-gl or the performance that is presented in React Native?

[gomes042]

Also, the process of creating a React Native project that supports Expo modules (Bare Workflow) still is complicated and confusing. Some people don't even intend to use other expo modules but need to change several things in their environment to use ThreeJS on react-native.

#2077

[CodyJasonBennett]

AFAIK expo-gl is the only option to run WebGL (2) natively. Understandably, it's quite an undertaking to implement WebGL bindings 1-1 from scratch. Webviews/PWAs would be more feasible (and IMO ideal) if it wasn't for Apple's app store monopoly, sadly we have to play by their rules.

I'd like to hear of alternative solutions or ways for us to better friction for bare workflows, but I'm afraid there's not much we can do ourselves. I also see some progress has been made on resolving related compat problems upstream, so maybe we can update that issue.

[CodyJasonBennett]

Did some more research & experimenting and found that expo-gl-cpp doesn't have a hard dependency on expo. I know there at one point was a reliance on a specific SoLoader version but it looks feasible to create Android/iOS interfaces without any dependency on expo at all.

Has anyone else tried this? Can reference expo-gl and all.

[gomes042]

Did some more research & experimenting and found that expo-gl-cpp doesn't have a hard dependency on expo. I know there at one point was a reliance on a specific SoLoader version but it looks feasible to create Android/iOS interfaces without any dependency on expo at all.

Has anyone else tried this? Can reference expo-gl and all.

Yes, I've been taking a look at how the expo builds their GL context along with the bindings for three and came to the same conclusion, unfortunately it seems that no one has tried to take this dependency off the expo in some forked solution yet 😞

[CodyJasonBennett]

I'll have to talk with Paul to see if this can be done upstream (so expo-gl works as a standalone) or here in pmndrs. Not needing to vendor/fork expo-gl-cpp is really attractive as a fail-case.

[gomes042]

I'll have to talk with Paul to see if this can be done upstream (so expo-gl works as a standalone) or here in pmndrs. Not needing to vendor/fork expo-gl-cpp is really attractive as a fail-case.

Any updates?

[CodyJasonBennett]

To update, this doesn't appear possible upstream at expo-gl. All expo modules rely on expo utils as part of their build configuration, and we'd need to vendor expo-gl-cpp to correctly publish/work with peer deps (there are ways around this, but vendoring is the easiest).

I think the next steps would be to put together a demo to feel for any new/remaining issues. As this would be a drop-in replacement for expo-gl loaders will no longer work locally with Metro over the filesystem, but I've made them optional in setups without expo with #2265. These polyfills only exist due to unimplemented interfaces in react-native but should work without for the sake of testing.

Long term, I'd still like to explore bgfx in the promise of a general WebGL/WebGPU solution. I'm a little uncomfortable with expo-gl-cpp's reliance on OpenGL support on iOS (AFAIK this is deprecated and the source of many woes ATM in WebGL bugs), so it would be nice to move to a translation layer on top of Metal to sidestep these issues.

[CodyJasonBennett]

I know it's been awhile but an interesting project that's caught my eye is https://github.com/NativeScript/canvas. I'm still wary of supporting WebGL over WebGPU without the backing of any company, but this looks more promising than expo-gl as-is.

[nica0012]

I cannot believe this hasn't been done outside of Expo!

I spent my whole weekend trying to get expo-gl to work with my BARE react native app. (Seems impossible, I gave up)...

@runtothedoor you're right, "the process of creating a React Native project that supports Expo modules (Bare Workflow) still is complicated and confusing." It is not even close, and I hope React Native does not push us to use Expo in the future.

[gomes042]

I cannot believe this hasn't been done outside of Expo!

I spent my whole weekend trying to get expo-gl to work with my BARE react native app. (Seems impossible, I gave up)...

@runtothedoor you're right, "the process of creating a React Native project that supports Expo modules (Bare Workflow) still is complicated and confusing." It is not even close, and I hope React Native does not push us to use Expo in the future.

Yes, a few years ago I had to switch from Three to BabylonJS / Babylon React Native due to the need to work with a native mobile scenario. Unfortunately ThreeJS, even with a beautiful API, ends up being limited by this barrier. It's complicated because maintaining a renderer library is not simple, it usually needs some people to do it in a stable way. The expo-gl by itself is not perfect but it could improve a lot if it were decoupled from the expo as well as other good libraries from them.

[CodyJasonBennett]

The core problem is lack of support. pmndrs isn't a large company like Microsoft, things take more time and effort since we do this for free in our spare time. It is possible to fork expo-gl and remove the runtime expo dependency, but it's hard and time consuming; yet this is something I've been working towards in my free time to hopefully upstream or publish in a fork (see previous discussion). Currently, I'm trying to tackle existing react-native issues that block critical JS buffer code pertinent to all graphics APIs. There are withstanding issues with expo-gl though, Apple deprecated OpenGL on all platforms so a Metal adapter would have to be written which more than doubles the maintenance effort of the bindings.

This will improve for sure once WebGPU is shipped in browsers since we already have a Rust API and C headers that could plug into JSI and maintain compliance with the spec — support is great since these are used directly in browsers. That is strictly better than any graphics option we have today in capability, performance, and maintainability. It's also notable that the need for WASM on the web will diminish with GPU compute, and its shader code along many others can be shared between web and native (not just react-native).

[tomdoeslinux]

With the introduction of Turbo Native Modules, would it be possible to directly interface with OpenGL ES and C++?