Mem shrink rlottie. #516
Open
Mem shrink rlottie. #516
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ndering in passes and does not require a `width * height * 4` bytes buffer anymore. On limited memory MCU, this will allow rendering a large animation by trading off memory for CPU consumption instead.
…se exponential growth on memory allocation. Only allocate what's required and not more.
…by JSON from X-Ryl669.
…tion for copying the data. The JSON file can now come from ROM/Flash
A Lottie file says the number of frames (from start to end, included) but rlottie was using start to end (excluded), leaving away the last frame of an animation. This commit fixes this so that all frames are included.
|
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. |
Open
X-Ryl669
force-pushed
the
memShrink
branch
2 times, most recently
from
fe888f5
to
270c6ba
Compare
X-Ryl669
force-pushed
the
memShrink
branch
2 times, most recently
from
d7a822b
to
c7915c6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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::stringwhich will allocate a buffer that's twice the required size due to exponential allocation algorithm instd::string(andstd::vectoras 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.