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.
this fixes the memory sanitizer report:
../src/savers/gif/gif.h:315:31: runtime error: index 255 out of bounds for type 'unsigned char [255]'
../src/savers/gif/gif.h:113:54: runtime error: index 255 out of bounds for type 'unsigned char [255]'
Issue: https://github.com/thorvg/thorvg/issues/1758
Add save() API that takes tvg::Animation as a parameter.
This API uses gif.h to create each animation frame as a gif frame.
Gif creation do not support threads because they must be added sequentially.
Please see example/GifSaver.cpp
ex)
auto animation = tvg::Animation::gen();
auto picture = animation->picture();
picture->load(EXAMPLE_DIR"/walker.json");
auto saver = tvg::Saver::gen();
saver->save(std::move(animation), EXAMPLE_DIR"/test.gif");
saver->sync();
New API:
Result Saver::save(std::unique_ptr<Animation> animation, const std::string& path, uint32_t quality = 100, uint32_t fps = 0);
Issue: https://github.com/thorvg/thorvg/issues/1712
../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
The Animation::frame() method has been modified.
It will now return InsufficientCondition,
if the frame value is the same as the previous one.
In addition to this change, we have also updated its usage accordingly.
Get rid of the polymorphism function table,
use the switch directly instead.
We profiled, both binary & performance is better than before.
Tested on a local machine (single thread):
- Lottie: 2ms improved
- Binary: -0.5kb
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
Unified common logic for scaled image raster operations,
Avoid on-spot pixel computation as possible.
Tested on local machine (single thread)
Lottie: 0.057s -> 0.053s (-0.004s)
Try to minimize the use of sqrt() and arctan() calls
when possible. These calls can be relatively expensive
when accumulated within a single frame.
Also repalce the division with shift operation.
since split cubic function is one of the significant hot-spots
in the data processing, we could earn a noticable enhancement.
Tested on single thread local machine:
Lottie: 0.080 -> 0.052s (-0.028s)
Performance: 0.023 -> 0.022 (-0.001s)
Binary: +34
Streamlining computations with floating-point operations in rotation
thereby improving 'thorvg' speed.
Also use the well-optimized posix math functions instead of
custom math.
Test on my local machine.
Lottie: -0.008s (0.073 -> 0.065)
Performance: -0.0013s (0.0154 -> 0.0141)
Binary: -323
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
Previously, the engine didn't properly cover the dash line corner styles
because it considered a new line to start at the corner.
This update modifies the logic to recognize curved lines
as a single line, including the corners.
There may still be some quality issues,
but it's an improvement over the previous version.
@Issue: https://github.com/thorvg/thorvg/issues/121
In this update, we have chosen not to include CAPIs.
This decision was made due to the mixture of C++ and C languages
in a single documentation category, which resulted in a messy presentation.
Also, In this update, we have removed 'doxygen-awesome-css'
and introduced our own designated styles located in the 'style' folder.
After generating the Doxyfiles, we can overwrite the styles with these new ones.
The color conversion is supposed to take into account the differences between
straight alpha premultiplied color and pre-multiplied alpha color.
The previous logic does not perfectly cover these conditions.
The problem was occured in the thorvg viewer with a jpeg bgra format.
