Implemented the ability to revert Lottie slots by calling override with nullptr.
This functionality allows for the complete reversal of applied slots.
usage:
- `animation->override(nullptr)`
Co-Authored-By: Hermet Park <hermet@lottiefiles.com>
When image data fails to load or image parsing fails,
the id is leaked without being assigned to the name.
To prevent that, free id value when obj is nullptr.
related issue: https://github.com/thorvg/thorvg/issues/2072
BrokenLottie.7z/test3_IDX_130_RAND_18289244608080059871.json
BrokenLottie.7z/test3_IDX_131_RAND_7772102071213376276.json
BrokenLottie.7z/test3_IDX_132_RAND_3072617087893397532.json
BrokenLottie.7z/test3_IDX_134_RAND_17738488813555566674.json
BrokenLottie.7z/test3_IDX_137_RAND_13903188963759129023.json
BrokenLottie.7z/test3_IDX_138_RAND_1645404078965858130.json
When json file is invalid in the parser,
the LottieComposition object is not released and the parse() returns false.
To prevent memory leaks, free the memory before returning false.
related issue : https://github.com/thorvg/thorvg/issues/2070
This commit addresses an issue where paints lost their
composition context when drawings occurred without any updates.
Now, paints will consistently retain the composition context,
ensuring accurate rendering.
Issue: https://github.com/thorvg/thorvg/issues/2058
Enhances the portability of the TTF loader on UWP platforms
by implementing an alternative file loading mechanism.
This is designed to support environments where the file mapping
feature is not available, ensuring wider compatibility and reliability
in file handling.
Issue: https://github.com/thorvg/thorvg/issues/1912
error: storing the address of local variable 'context' in '*this.LottieParser::context' [-Werror=dangling-pointer=]
1255 | this->context = &context;
issue: https://github.com/thorvg/thorvg/issues/2051
sw_engine: radial gradient
[issues 2014: radial gradient](#2014)
Radial gradient results in a corrupted image when the focal point is outside the circle on Apple Silicon.
This happens because some compilers use FMA to optimize the a = dr² - dx² - dy² calculation,
which cause loss of precision.
We rely on temporary variables to prevent FMA.
We could also use compiler specific float contraction control pragmas to avoid this if this doesn't work in the future
The previous loader cache mechanism encountered a problem
when the user changed the content of the cached data.
In such cases, a new request would not be processed
because the renderer would use the previously cached content.
So far, the TVG cache mechanism utilizes a pointer hash key
for the fastest hashing mechanism available.
One limitation is that it assumes the address is unique for the data.
To resolve this, we modified the caching policy.
Now, the renderer will not cache copied data;
it will only cache the given data when it is deemed shareable.
issue: https://github.com/thorvg/thorvg/issues/2020
After introducing the length measurement
of approximate and exact Bezier curves in
a8c0030d80
the calculation of the outline length still
used the approximate functions, while further
calculations took the exact value into account.
This discrepancy led to the creation of artifacts.
@Issue: https://github.com/thorvg/thorvg/issues/2021
stroke line drawing has been broken at a certain case,
this reverts a part of change from the old optimization:
d81f5d29fb
note that this change wouldn't affect any performance.
issue: https://github.com/thorvg/thorvg/issues/2015
According to the SVG standard, drawing a rectangle
starts at (x+rx, y) point. Till now it was (x+w, y+ry).
The difference was visible only for dashed strokes.
According to the SVG standard, drawing a circle/ellipse
should start at the '3 o'clock' position and proceed
in a clock-wise direction. Until now, this point was
set at '12 o'clock'.
The differences in the outcome were visible for dashed
strokes.
issue: https://github.com/thorvg/thorvg/issues/1686
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
these experimental apis are allowed to use
when the lottie loader is enabled.
APIs:
- Tvg_Animation* tvg_lottie_animation_new()
- Tvg_Result tvg_lottie_animation_override(Tvg_Animation* animation, const char* slot)
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
In the case of non-uniform scaling for
thick strokes, artifacts were visible.
The calculations took into account the angle
resulting from the already transformed points,
whereas the untransformed points should have
been considered - the transformation is taken
into account in the next step.
@issue: https://github.com/thorvg/thorvg/issues/1915
