Dear @kisvegabor
Do you know about the Rive App?
Take a look this example by @jctoon
This is an example of a state machine that you can use in Android, because the Rive Android runtime now supports state machines. #Bones #Icons #Characters #Android #StateMachine
References:
It’s not clear to me how it compares to rlottie. Do you know it?
There are many ways to create Lottie files.
The most popular is Adobe After Effects.
Rive is the new After Effects for UI and Motion graphic designers.
That the same file generated can be imported and interact with the app natively.
Take a look this example
You can play with the animation with the toggle button in the right panel.
I see. So Rive has its own format but can export to lottie too?
The main developer of Lottie is working officially to Rive to build the export features from Rive to Lottie and Lottie to Rive.
But the idea is to parse the Rive file format and use with LVGL for MCUs.
Cheers.
Got it. Similarly to lv_lib_rlottie just for Rive.
Do have time/interest to try porting Rive to LVGL?
Yes, I will looking for it.
Rive is very useful in my team.
Any plan for the project management let me know.
Thank you very much.
Great! Let me know if you need help with the LVGL specific part.
Any update on Rive for inexpensive CPU embedded systems via LVGL? Shouldn’t be too dissimilar from Tizen support. Maybe Tizen’s ThorVG [1] might provide some inspiration. There was a discussion of Rive on LVGL I found in this Espressif Github Issue [2].
[2] 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.
Post on Rive discord on LVGL support.
Hi,
Unfortunately, there isn’t much update yet. We are working on reworking the rendering architecture of LVGL and we have a “Vector graphics support” milestone in it.
So in the near future we need to pick an SVG library (I think it wouldn’t be reasonable to create our own) and integrate it into LVGL. It could be ThorVG or the engine of rlottie, I’m really not sure yet.
Regarding Rive, it provides some great features for sure (e.g. states), but I need to look into it in more detail.
Hello, LVGL could support SVG using ThorVG, and then replace the rlottie part when ThorVG also supports Lottie. It is expected to be released in the coming year. 
Is ThorVG suitable for MCUs too? Do you know the typical binary size for SVG only?
I’m not certain about the MCU’s compatibility, but if your MCU’s build toolchain supports C++14, then ThorVG should work similarly to rlottie. (as far as I know lvgl adopted the rlottie)
Consider the size of ThorVG with only the SVG loader: 192KB. The breakdown is as follow:
text: 182005
data: 9376
bss: 88
dec: 191469
hex: 2ebed
filename: libthorvg.so.0.9.99
Based on this information, I am confident that ThorVG is considerably smaller than other decent SVG engines, even when considering its raster component. You can review the history for more details.
Furthermore, you can potentially reduce the binary size by utilizing the shared raster engine of ThorVG for both Lottie and SVG implementations, if you choose to replace rlottie with ThorVG."
Sounds great! As I mentioned it’s on the roadmap to dive deep into the SVG engines. ThorVG seems like a really good candidate.
jyi, Lottie feature has been submitted to the thorvg.
Amazing 
Thank you for letting us know.
In the meanwhile we started to establish a vector API for LVGL, so I believe we will start working with ThorVG soon!