Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make expo-gl and expo-assets optional #3354

Open
CodyJasonBennett opened this issue Sep 13, 2024 · 6 comments · May be fixed by #3355
Open

Make expo-gl and expo-assets optional #3354

CodyJasonBennett opened this issue Sep 13, 2024 · 6 comments · May be fixed by #3355

Comments

@CodyJasonBennett
Copy link
Member

CodyJasonBennett commented Sep 13, 2024

As described in #3352 and #3353, there is a need to swap the runtime under the Canvas when rendering with a WebGPU context or other alternative (e.g., Skia, ANGLE). expo-gl should be at minimum optional for those creating a custom canvas with their own runtime.

Polyfills should exit gracefully if any expo modules they depend on are not present.

@wcandillon
Copy link

just for reference, this is how we've handled optional dependencies in React Native:
https://github.com/Shopify/react-native-skia/blob/main/packages/skia/src/external/reanimated/ReanimatedProxy.ts
This pattern has worked well for us. This would indeed allow us to use three-fiber with WebGPU without installing expo-gl for instance.

@CodyJasonBennett CodyJasonBennett linked a pull request Sep 13, 2024 that will close this issue
@CodyJasonBennett
Copy link
Member Author

Have you run into this issue with Metro facebook/metro#666? Trying my hand at it in #3355 and I'm unable to find a workaround.

@wcandillon
Copy link

In its current form this approach as been working well for us and for https://github.com/mrousavy/react-native-vision-camera.

The three-fiber reconciller is so platform agnostic that I am surprised you offer different build of it for different platforms instead of offering varieties of canvases.

@CodyJasonBennett
Copy link
Member Author

The reconciler isn't the one writing <canvas />, but as an aside, what do you think of R3F pulling in an HTMLCanvasElement API that can give you a 2D/WebGL/WebGPU context? The motivation is to avoid back-end-specific components and use web code where possible. This is far from the endgame my colleagues at Callstack are working on (which we're trying to include you in), including bettering WebGL support, but it's a stopgap until anything happens upstream. Still, I'll look through since I'm not 100% reproducing your workarounds so far for this issue.

@wcandillon
Copy link

wcandillon commented Sep 16, 2024

What you are describing is exactly our vision. We describe it at https://www.youtube.com/watch?v=i-DGY98cTjk
While working on <Canvas /> we stumbled on a generic canvas API that can spawn any context (skia, webgpu, filament, opengl, you name it).

This "generic" canvas APIs has been already used in prototypes where it spawn a Skia context and the results have yield substantial benefits.

Our focus with React Native WebGPU was to enable people to copy/past example from the web and have them work immediately: https://github.com/wcandillon/react-native-webgpu?tab=readme-ov-file#similarities-and-differences-with-the-web
The only difference that can be spotted is that we use <Canvas /> instead of <canvas />.

@CodyJasonBennett
Copy link
Member Author

I mean something that is actually compliant with the web and can be ingested in the three ecosystem—meaning it can spawn a 2D/bitmap/WebGL/WebGPU context and later integrate with W3C pointer events. Skia and OpenGL are implementation details, Filament is just a renderer; it is unrelated. The correctness is incredibly important, and React Native has realized that individually porting and maintaining modules is unsustainable, and it has to stop if we are to unify and build such high-level APIs. This was the main topic of the contributors' summit, and there are many other efforts to port WebGPU and WebGL besides our own, all duplicate and ununified. That's only going to slow us down if we can't get in the same room together or work in an open forum, especially with such ambitious goals to align with web. The stopgap I suggested is shimming what we can if you want something before this is done properly upstream, and all things considered, that could be measured in years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants