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.
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.
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 astd::string
which will allocate a buffer that's twice the required size due to exponential allocation algorithm instd::string
(andstd::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.