Previously, the Lottie parser expected a specific parsing order:
font followed by glyph, for optimal data processing.
However, since this order is not guaranteed,
we have revised the parsing logic to accommodate any order.
resolved a corner case where assets were being attached
multiple times during scene building. This issue was causing
a significant performence drop in image animation
in certain scenarios.
XOR when the shape's direction property is set to a value of 2.
Currently, the direction property is expected to have
either 1 for clockwise or 3 for counterclockwise orientation.
Just found out the number 2 use-case...
Previously, multiple gradients within a single group
couldn't be accounted for during rendering.
This fix addresses the scenario by fragmenting the rendering context.
Each group must determine the stroking rendering contexts
and assess whether context switching has occurred.
Migrate the sequence from the root layer to all groups.
enable exceeding the range of normalized values in time remapping.
the issue came from a misunderstanding of the lottie spec.
issue: https://github.com/thorvg/thorvg/issues/1809
The loader cache is applied to conserve memory.
If the input data is already present in loaders,
the loader cache will promptly return the active loader.
This results in a lot of memory savings for the duplicated resources.
binary diff: -400 bytes
I've added new parameter, const string& resourcePath, to load external image on lottie.
Result load(const char* data, uint32_t size, const string& mimeType, bool copy, const string& resourcePath)
Note: tvgLoadModule will have new overrided method `open`, not to effect to other changes except animation.
Issue: #1793
There are some matting masking bugs observed,
Reverted the commit. We will revisit it later.
commit d37c500262
Author: Hermet Park <hermet@lottiefiles.com>
Date: Wed Oct 25 18:55:05 2023 +0900
lottie: introduced static layer cache.
lottie builder doesn't need to rebuild the layer object
if it has no any animation frame data.
That case, we can cache the layer scene in order to reuse it.
Tested on local machine (single thread):
- Lottie: appx. 2ms enhanced.
- Binary: +204
Currently, it assumes "ty":"gr" for the related shapes children,
which can be skipped since the children will be in the "it" scope.
Some Lottie data is missing the "ty":"gr" field,
and ThorVG couldn't display the content properly.
It can ignore it with the context understanding.
Previously, Picture::load(const char* data, uint32_t size, const std::string& mimeType, bool copy = false)
would return 'Success' even when the data is invalid.
This issue only occurred when the number of threads is set to 0.
lottie builder doesn't need to rebuild the layer object
if it has no any animation frame data.
That case, we can cache the layer scene in order to reuse it.
Tested on local machine (single thread):
- Lottie: appx. 2ms enhanced.
- Binary: +204
replace the frame count unit from the int32_t to float
since animations could smoothly interpolate key-frames.
This notificably improve the animation smoothness in Lottie
Beta API changes:
Result Animation::frame(uint32_t no) -> Result Animation::frame(float no)
uint32_t Animation::curFrame() const -> float Animation::curFrame() const
uint32_t Animation::totalFrame() const -> float Animation::totalFrame() const
Previously, the builder accumulated the outlines and fills
in one paint to reduce the rendering context.
However, this approach won't work for Lottie
if the resource contains multiple strokes with branched groups.
We should apply the optimization
only when the specified condition is satisfied.
Revised the rendering logic of Lottie by creating a new rendering context
using a queue when multiple strokes are requested.
Issue: https://github.com/thorvg/thorvg/issues/1642
This correction ensures a consistent use of 'ref' and 'unref' for paints to release memory properly.
The memory leak occurred when a picture was not pushed to a valid canvas.
This issue was reported by the unit-test memory sanitizer.
