deprecate the `identifier()` APIs by replacing them with `type()`.
ThorVG is going to introduce an instance `id()`,
and this could be confused with the `identifier()` methods.
with this new type() method can reduce the memory size
by removing unncessary type data.
New Experimental C APIs:
- enum Tvg_Type
- Tvg_Result tvg_paint_get_type(const Tvg_Paint* paint, Tvg_Type* type)
- Tvg_Result tvg_gradient_get_type(const Tvg_Gradient* grad, Tvg_Type* type)
New Experimental C++ APIs:
- Type Paint::type() const
- Type Fill::type() const
- Type LinearGradient::type() const
- Type RadialGradient::type() const
- Type Shape::type() const
- Type Scene::type() const
- Type Picture::type() const
- Type Text::type() const
Deprecated C APIs:
- enum Tvg_Identifier
- Tvg_Result tvg_paint_get_identifier(const Tvg_Paint* paint, Tvg_Identifier* identifier)
- Tvg_Result tvg_gradient_get_identifier(const Tvg_Gradient* grad, Tvg_Identifier* identifier)
Deprecated C++ APIs:
- enum class Type
- uint32_t Paint::identifier() const
- uint32_t Fill::identifier() const
- static uint32_t Picture::identifier()
- static uint32_t Scene::identifier()
- static uint32_t Shape::identifier()
- static uint32_t LinearGradient:identifier()
- static uint32_T RadialGradient::identfier()
Removed Experimental APIs:
- static uint32_t Text::identifier()
issue: https://github.com/thorvg/thorvg/issues/1372
NonSupport indicates unsupported options due to disabled features
or lack of system support. InvalidArgument indicates the case
such as incorrect parameter values.
The functions setting stroke's features always
returned a true. Returnig a boolen was a remnant
from a previous implementation. Since now they
never return false, they can be void functions.
The APIs description has been corrected.
New api sets/gets the trim of the stroke
along the defined path segment, allowing
control over which part of the stroke is
visible.
@issue: https://github.com/thorvg/thorvg/issues/2190
For angles close to multiples of pi/2, precision
based on FLT_EPSILON was insufficient. It either
led to the creation of an additional cubic segment
filled with erroneous values or NaNs, or it resulted
in the drawing of an angle for a sweep close to 0.
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
adjusted the starting position of the rounded rectangle to 90 degrees
to ensure compatibility with the Lottie trim path effect.
This modification follows the earlier circle correction applied to the rectangle.
issue: https://github.com/thorvg/thorvg/issues/1933
the bug was introduced in 9bf8bb018d.
Migrated the circle commands to the rectangle, which is currently necessary.
Retained the previous circle commands for backward compatibility.
Adjusted the path's start point to 90 degrees
to align the origin consistently with other path commands.
No compatibility issue, this only could affect the trimpath effects.
The magic number kappa (0.552284), which is associated with the bezier curve,
has been introduced. This formula is supposed to be applied to the rounded corners
of the rectangle to ensure consistent drawing results.
Issue: https://github.com/thorvg/thorvg/issues/1824
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
