ttf is an industry standard format that is the most widely used
in the products. Now thorvg supports the basic features of
the font to supplement the text drawing.
The implementation is followed the ttf spec,
the covered features are:
- horizontal layouting with kerning.
- utf8 -> utf32 converted glyph drawing.
To use the feature, please enable ttf loader:
$meson -Dloaders="ttf_beta, ..."
@Issue: https://github.com/thorvg/thorvg/issues/969
We are introducing the FontLoader, which slightly differs
from the ImageLoader in terms of features. To adequately
support both, we have separated the loader functionalities
into FontLoader and ImageLoader. This allows us to optimally
adapt the LoadModule for each case.
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
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.
../src/loaders/external_png/tvgPngLoader.cpp(110): warning C4244: '=': conversion from 'float' to 'uint32_t', possible loss of data
../src/loaders/external_png/tvgPngLoader.cpp(111): warning C4244: '=': conversion from 'float' to 'uint32_t', possible loss of data
../src/loaders/external_png/tvgPngLoader.cpp(112): warning C4244: '=': conversion from 'float' to 'uint32_t', possible loss of data
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.
Lottie ColorStop RGB / Alpha can be dealt with individually.
Since thorvg handles this one unified set,
lottie model need to merge the data into one structure.
