Motivation for using FFI?

[chipweinberger]

Really cool library! I love that it supports runtime compilation.

I was curious, why did you use FFI & FFI gen?

It seems more complicated than platform channels + Java & C, especially by requiring a ffigen build step, ndk, CMake, glw, and a c++ compiler. That's very significant complexity!

Not trying to critique, just want to understand the motivation.

[alnitak]

Hi @chipweinberger. Using method channel you are bounded to use the platform native language. In this case there is no need to do that for all bindings to the OpenGL lib. The only method channel I used here, is to ask the native platform to build a native window for the Texture() widget.

If you used method channel for all the OpenGL, you should write in native platform code all the bindings to the C side: Dart => platform native language => C and here the platform language could be [java|kotlin|maybe NDK], [swift|objectiveC], linux GTK, Windows. Saying this you must know 4 different platforms and I am not that guy ;)

while using Dart:FFI: Dart => C here from Dart, using ffiGen, your functions are instantly accessible from Dart.

Also consider that doing so you have a single code base in C/C++ that let you code one to rule them all (almost). And you also avoid to develop a Federated plugin which complicate things a little more.

I hope I explained myself, feel free to continue this discussion!

[chipweinberger]

yes that makes sense given that opengl has a C api on each platform.

but we don't need to expose very much C code to dart, just the ability to load some shaders.

but I suppose given the name of this project you aspire to expose all of opengl to dart?

in that sense, maybe this approach is preferred.

---

in my use case i just want to load shadertoy shaders.

on android it looks like they expose opengl with a java wrapper (since API 1!) so you can just do dart -> java without NDK, c++, etc

linux would be dart -> C

ios would be dart -> Obj-C/C

all the platform code could easily live in a single file, per platform.

the code base would have more duplication, yes, but it would also have much lower complexity. no CMake, no C++ compiler, no NDK, etc.

duplication is cheaper than extra build complexity, imo.

[alnitak]

but we don't need to expose very much C code to dart, just the ability to load some shaders. but I suppose given the name of this project you aspire to expose all of OpenGL to dart?

Well, I started this project in 2019 with also some 3D support. With this in mind, directly exposing OpenGL functions was the direction I was thinking. But then I started to develop a music player with the need to add to the same code base also the audio lib. So I leave it as it was (with just shaders). Then last year I restarted this and Flutter announced shaders :)

the code base would have more duplication, yes, but it would also have much lower complexity. no CMake, no C++ compiler, no NDK, etc.

I think the approach you are referring to is done by making a Federated Plugin which "separate" the code for each platform. But IMHO cmake, c compilers will still be needed in linux and windows. Maybe not on android if you would like to use the java wrapper. On iOS and Mac there could be another approach based on Metal. And on web, WebGL or better WebGPU with javascript and wasm. I can't handle all these :). At least not alone!

Nice conversation BTW ;)

[chipweinberger]

Then last year I restarted this and Flutter announced shaders

yes if only it supported runtime shader compilation!

cmake

the code would be simple enough to just use the C compiler that ships with linux imo. no cmake needed. probably same for windows.

but im not an expert on linux or windows.

[alnitak]

well, android, linux and windows do use cmake by default. You can find cmakelists.txt in the respective folders. So not much hassle to add some c source and libs there (almost :) )