All our current dependencies (libvips and raylib) are just c/c++ libraries, from a development standpoint it's easier to have those installed on the system (esp when testing on a pi 0) than to compile them in with our current golang bindings (govips and raylib-go)
it's easier to let buildroot cross-compile rayimg a binary then send it to the device than it is to either x-compile using just go (armv6 is a pain) or build on device (compiling golang on a pi is more doable, but still slower)
also worth noting that cross-compiling with CGO is what makes this more complicated
Tuning go and its GC to work on embedded systems is fun...
GOMAXPROCS defaults to all processors, but does it need to be for this single threaded app?
The memory management seems a little liberal. Ideally we want as little memory use as possible so the system can cache files in memory for quicker loading of images on a loop
Potential Fixes with golang
Look into better/different embedding solutions
See if there's any tuning recommendations for golang on embedded systems
Switch to an pure go solution (not very likely due to the wide moving target of new image formats)
Would make x-compilation a lot easier!
Potential Fixes with LuaJIT
Easier access to other c/c++ libraries in the future that may or may not have golang bindings (eg: a different gif library, ffmpeg? custom hw decoding?)
Faster to stay updated with all libraries as well (don't have to wait for updated bindings, just need to be able to compile the library)
Much easier embedded development:
Install all libraries on dev system (likely only need to do this once)
Copy over the new lua files (just an rsync not a compilation!)
Run
Lua is better designed to work on embedded platforms and will likely have lower memory usage (don't have to tune the GC).
Issues with LuaJIT
Would need to create our own bindings. LuaJIT's ffi is amazing however.
Only really using a little bit of raylib (enough to display and load images really)
I started this project in an attempt to learn golang, but I think the heavy reliance on c/c++ libraries and running on an embedded system made this the wrong choice. I think the biggest win in switching to LuaJIT is easy testing on device, very easy to create bindings to shared libraries, and [likely] better memory management on device.
It seems a little odd switching when rayimg basically works and does what we need. The arguments are a little weak, but I'm thinking about future features and integrations with more c libraries, compilation (and thus development) will only get slower.
Current problems
GOMAXPROCSdefaults to all processors, but does it need to be for this single threaded app?Potential Fixes with golang
Potential Fixes with LuaJIT
Issues with LuaJIT
Final Thoughts
I started this project in an attempt to learn golang, but I think the heavy reliance on c/c++ libraries and running on an embedded system made this the wrong choice. I think the biggest win in switching to LuaJIT is easy testing on device, very easy to create bindings to shared libraries, and [likely] better memory management on device.
It seems a little odd switching when rayimg basically works and does what we need. The arguments are a little weak, but I'm thinking about future features and integrations with more c libraries, compilation (and thus development) will only get slower.