This class extends the Animation and serves advanced Lottie features.
It's designed to separately have Lottie Animation's unique specs.
For now, this will have Slot overriding feature,
you can include <thorvg_lottie.h> for its extensive features.
@APIs:
- Result LottieAnimation::override(const char* slotJson) noexcept;
- static std::unique_ptr<LottieAnimation> LottieAnimation::gen() noexcept;
@Issue: https://github.com/thorvg/thorvg/issues/1808
Internal model and parser modifications have been made
to parse "sid" and retrieve their data into the LottieComposition.
This will enable dynamic changes to the following Lottie objects:
The slot feature will encompass these properties:
- LottieSolidStroke
- LottieSolidFill
- LottieGradientStroke
- LottieGradientFill
- LottieTextDoc"
Issue: https://github.com/thorvg/thorvg/issues/1808
Co-authored-by: Hermet Park <hermet@lottiefiles.com>
To ensure consistent properties, `LottieSolid` has been defined.
Both `LottieSolidStroke` and `LottieSolidFill` can be typecasted to the `LottieSolid`.
Improve parenthesis checking and space checking.
- There must be only one pair of parentheses.
- There cannot be spaces(and ') between id strings.
Issue: https://github.com/thorvg/thorvg/issues/1983
Co-authored-by: Hermet Park <hermet@lottiefiles.com>
Dashed curves require greater precision in calculating
their lengths and while splitting Bezier curves.
Otherwise, it results in visual discrepancies compared
to the expected outcomes.
Approximate functions 'bezLengthApprox' and 'bezAtApprox'
used for calculations in the lottie loader.
issue: https://github.com/thorvg/thorvg/issues/1686
enhance decoding efficiency by determining the desired canvas format
during image loading. This allows loaders to preemptively decode
the image in the specified format, to not convert the format again.
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.
The three specifications below apply.
Specification: https://www.w3.org/TR/SVG/paths.html#ArcOutOfRangeParameters
-
If the endpoint (x, y) of the segment is identical to the current point
(e.g., the endpoint of the previous segment),
then this is equivalent to omitting the elliptical arc segment entirely.
-
If either rx or ry is 0, then this arc is treated
as a straight line segment(a "lineto") joining the endpoints.
-
If either rx or ry have negative signs, these are dropped;
the absolute value is used instead.
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
Introduced a dedicated mutex for each surface instance
to ensure safe sharing between the loader, renderer, and engine.
This enhancement allows for secure modification and access to bitmap data,
addressing potential concurrency issues.
Multiple Picture instances can now safely share a single loader instance,
optimizing performance.
This change builds upon the previous Loader Cache improvements:
ff6ea4b6c4
