At the construction stage, some stroke points can be skipped
if the distance between the points is too narrow.
Previously, this was assumed to be an error case,
but it's clearly intended to remove unnecessary points introduced in a small area of drawing.
This sometimes leads to a flickering issue when super small-sized vector images are drawn.
Now, it's fixed.
[29/73] Compiling C++ object src/libthorvg.a.p/lib_sw_engine_tvgSwStroke.cpp.obj
../src/lib/sw_engine/tvgSwStroke.cpp(258): warning C4244: 'argument': conversion from 'float' to 'int64_t', possible loss of data
[32/73] Compiling C++ object src/libthorvg.a.p/lib_sw_engine_tvgSwRaster.cpp.obj
../src/lib/sw_engine/tvgSwRaster.cpp(259): warning C4244: 'initializing': conversion from 'float' to 'uint32_t', possible loss of data
../src/lib/sw_engine/tvgSwRaster.cpp(260): warning C4244: 'initializing': conversion from 'float' to 'uint32_t', possible loss of data
We have an incorrect value comparison when the stroke corner center
is adjusted. All coordinates in the stroke raster have been scaled by
the given values (sx, sy), while the stroke width remains at its
original size due to it not being clear how it should be scaled.
This brings wierd rendering results at times. Now fix it.
@Issue: https://github.com/thorvg/thorvg/issues/1336
re-design the shape data structure so that render backends
are able to access them directly.
This also let us remove tvgShape member data from the Shape::Impl.
To achieve this, migrate shape/stroke/path
from the canvas interface to the render interface.
if many canvas instances own private memory pool,
the memory usage can be increased linearly.
To prevent memory usage, flush out memory pool from the clear()
if the canvas uses private memory pool.
We have encountered that multi-threading usage that user creates,
multiple canvases owned by multiple user threads.
Current sw_engine memory pool has been considered only for multi-threads,
spawned by tvg task scheduler.
In this case it's safe but when user threads introduced, it can occur race-condition.
Thus, Here is a renewal policy that non-threading tvg(initialized threads with zero),
takes care of multiple user threads bu changing its policy,
each of canvases should have individual memory pool to guarantee mutual-exclusion.
@API additions
enum MempoolPolicy
{
Default = 0, ///< Default behavior that ThorVG is designed to.
Shareable, ///< Memory Pool is shared among the SwCanvases.
Individual ///< Allocate designated memory pool that is only used by current instance.
};
Result SwCanvas::mempool(MempoolPolicy policy) noexcept;
All in all, if user calls multiple threads, set memory pool policy to Individual.
* sw_engine: adding a gradient as a stroke feature
Similarly as a shape may have a gradient fill so can the stroke.
* Capi: adding APIs for a gradient stroke
Co-authored-by: Hermet Park <hermetpark@gmail.com>
we should avoid code insertion during file dependencies,
such as #include "xxx.h" which has implementations.
This could increase binary size, we can avoid it as possible.
Current patch improves binary size like this:
From: file(2059008) = text(120360) data(8096) bss(80) dec(128536)
To : file(1921832) = text(118429) data(7872) bss(56) dec(126357)
More additional patches will come in to optmize binary size.
remove unnecessary condition.
implementation won't be included multiple times not like headers.
Thus this condition is unnecessary.
Change-Id: Id37e675c40ce7213a06c950da8e5ca17ff7245c9
Now, stabilizing is pretty enough.
Remove assert code so that we never abort process in any cases.
This also reduce the binary size.
Change-Id: Ia7d2d5c5a0757b12481eaebad7a86aade6a89c1e
we can't control any threads count that could drop the performance.
remove async() and will come back with fine-tuned threading-pool.
Change-Id: I17c39792234acfce6db334abc0ce12da23978a9a
these conversions are intented, we explicity use casting so that compiler doesn't
catch them anymore.
Change-Id: I9d905c7562c43929b040d034e5ee0d14c6750a80
previous fast track logic is useless,
it actually doesn't helpful for performance, just increase the code complexity.
Change-Id: Ib6ad204edfb241d74c41413dfec7ab42fb02af81
if the transform scale factor for x/y is not identical,
it keeps its both xy scale factor then apply them
for stroking calculation.
Change-Id: I519dfce3ce7b4a12c13da1801d6a00e139e7400f
Basically, stroke width size is linear,
engine couldn't apply scale factor from the matrix which contains 2 dimensional values.
Thus, we can apply it if the scale factor of x/y is identical.
Otherwise, we should transform every stroke points in the stroking process.
That scenario can be improved with another patch.
Change-Id: I070dcf29d2e42f21e182bdf4239781464158ef73
../src/lib/sw_engine/tvgSwStroke.cpp:282:72: error: no match for ‘operator<’ (operand types are ‘long int’ and ‘const SwPoint’)
if (border->ptsCnt > 0 && abs(diff.x) < EPSILON && abs(diff.y) < EPSILON) return;
Change-Id: I426f8980ba718e3dc908dc32a62fb897b5b5fbbf
