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
For shapes with a stroke that has opacity, anti-aliasing
should be applied to a fill.
The use of a transparent gradient stroke will also be handled
correctly.
For gradients with fill spread set as repeat,
the lack of anti-aliasing between the last and
the first color caused noticeable jagged edges.
Interpolation was introduced between them,
visually improving the gradient quality.
When checking the fastTrack condition,
it's necessary to exclude the outlines
with a Bezier curve (Move-Cubic-Line,
Move-Cubic-Close, Move-Line-Cubic).
@Issue: https://github.com/thorvg/thorvg/issues/2379
For the 'simultaneous' trimming option, the maximum
stroke length from all subpaths was determined and
used to scale the trim of each subpath. As a result,
if the subpaths had different lengths, this scaling
was incorrect.
Now, the length is determined separately for each
subpath and is used to scale the trimming of its stroke.
@Issue: https://github.com/thorvg/thorvg/issues/2335
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
Rather than aiming for extremely high accuracy,
a compromise can achieve with better performance.
This modification helps prevent unnecessary image rotation.
issue: https://github.com/thorvg/thorvg/issues/2265
The viewport function defines the rectangular area of the canvas
that will be used for drawing operations.
It is used to clip the rendering output to the boundaries of the rectangle.
Apps can use this function to set the drawing region within the canvas.
When the ThorVG canvas is partially inside the screen area such as during scrolling
it could help enhance rendering performance.
New Experimental API:
- Result Canvas::viewport(int32_t x, int32_t y, int32_t w, int32_t h) noexcept;
Issue: https://github.com/thorvg/thorvg/issues/2274
The error was visible when multiple shapes were
simultaneously trimmed. The length of a single
shape was zeroed out only in selected cases,
which caused accumulation that could lead to
incorrect extension of the variable determining
the maximum length.
@issue: https://github.com/thorvg/thorvg/issues/2173
There are differences in behavior compared to the SVG spec,
especially when consecutive line drawings occur without a moveTo command
following a closePath command.
Actually, thorvg didn't care the behavior in that scenario,
this update ensures the scenario is handled correctly
to align with the SVG specification.
issue: https://github.com/thorvg/thorvg/issues/1487
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
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
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
