The lottie format defines the starting point for
drawing rectangles and ellipses differently than
the API available in the TVG. In the case of using
dashes or trim paths, this leads to discrepancies.
Therefore, when using the lottie builder, internal
functions for appending rectangles and circles are
utilized.
@issue: https://github.com/thorvg/thorvg/issues/1997
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
