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 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
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.
While it may represent a dot with a stroke width,
ignoring its length is not a good idea.
this also eliminates 0 size dash dots caused by unexpected empty lengths.
Previously, a mechanism was introduced to skip antialiasing computations
when shapes are invisible due to their stroking. However, this mechanism
failed to account for the scale factor of the stroke; it only considered
the current stroke width as a threshold.
Consequently, when the stroke width is scaled up to a value smaller than
the threshold, the incorrect antialiasing approach is applied. This results
in the appearance of jagged edges.
The implemented fix rectifies this problem and ensures that the antialiasing
computation correctly takes into consideration both the visibility and the
scale factor of the stroke width.