Samsung / rlottie

A platform independent standalone library that plays Lottie Animation.
Other
1.15k stars 223 forks source link

Mem shrink rlottie. #516

Open X-Ryl669 opened 2 years ago

X-Ryl669 commented 2 years ago

I'm trying to use rlottie on ESP32. It's a very capable embedded system but with few memory (hundred of kB of heap space only)

This PR contains many work to reduce the memory consumption of rlottie:

Using partial rendering

This is in a separate PR #512 . Basically, it allow to use a much smaller rendering buffer

Replacing RapidJSON

RapidJSON might be rapid (not sure about this true), it's not memory efficient. Parsing with RapidJSON implies allocating a buffer that's the same size as the lottie's JSON file in the heap. On memory constrained system, it's a no-no. So I'm replacing it with my own JSON SAX parser that's able to parse a read only string. The parsing is much simpler and a lot more memory efficient since you can use a flash based filesystem to map the rlottie JSON file in address space (like ESPFS on ESP32) and avoid consuming the heap at all. My parser is slower than RapidJSON on AMD64 system, but faster on ESP32. I guess it's due to not implementing SIMD optimization on AMD64/x86 in my parser.

Avoiding typical STL memory dumbness.

When using std::getline(), internally, it append char by char on a std::string which will allocate a buffer that's twice the required size due to exponential allocation algorithm in std::string (and std::vector as well). So if you have a JSON file that's 16385 bytes, you'll end up using 32768 bytes of heap. I've removed this since the file size is known beforehand so we can allocate the exact amount required.

Fix a off-by-one error in frame handling

Rlottie does not allow rendering the last frame of an animation. This PR fixes it.

X-Ryl669 commented 2 years ago

Using valgrind as a memory allocation benchmark, on a 24kB lottie JSON file, I've shrinked the heap memory usage from 380kB down to 290kB with my patch.