Any update on Rive for inexpensive CPU embedded systems via LVGL? Shouldn’t be too dissimilar from Tizen support. Maybe Tizen’s ThorVG  might provide some inspiration. There was a discussion of Rive on LVGL I found in this Espressif Github Issue .
GitHub - thorvg/thorvg: ThorVG is a platform-independent portable library that allows for drawing vector-based scenes and animations, including SVG. It provides user-friendly APIs, has no dependencies, and maintains a super compact size.
 Compiling with Lottie Library enabled in LVGL configuration · Issue #8 · espressif/esp-box · GitHub
In short, for light interfaces with 3 animated icons, I think we can work with the DRAM heap (that’s around 180kB) and gain a good 3 to 4x the performance instead of using the SPIRAM.
Last possible solution to optimize more would be to change rlottie code to use hash instead of strings for its few unordered_map in order to avoid most useless heap allocation for std::string. Maybe we could gain another 1 to 2kB here. But it’s not the low hanging fruit anymore…
I don’t think ThorVG will be the panacea either. It has many advantages but a lot of cons for me:
There are too few software to create rive file and none are open source (unlike lottie format that’s usable with Glaxnimate, Synfig, Haiku, …)
Code doesn’t fit true embedded platform very well
SVG is larger than lottie format (XML vs JSON), so for simple vectorial icons stored in flash, lottie is better (and with my branch, it’s not required to load the json file in the heap, it can be parsed from flash directly). Their binary mode (.thorvg format) is just about the same size as uncompressed lottie file.
lottie support in ThorVG isn’t there. I doubt it’ll happen soon
rive support is another repository that’s using enlightenment’s primitive so it needs to be disentangled to be used in LVGL.
There’s no cmake support, so it has to be written from scratch.