The following is a redesign that extends the class internally.
The main goal is to preserve the characteristics of the pImpl idiom
for data encapsulation, while simultaneously reducing the memory
allocation overhead typically associated with pImpl.
The stragegy is here:
Rather than alloc the impl memory inside of the thorvg engine,
impl extends the API classes in order to consolidate the memory.
size has been decreased by -4kb with optimization=s
issue: https://github.com/thorvg/thorvg/issues/3214
The shadow color produced incorrect results after
blending with the texture color. This was caused
by not taking the alpha value into account in the
specified shadow color (with OpenGL blending disabled).
While dashing, changing the path command each time caused
a new 'move to' command to be added, even when dash segments
across different path commands should have been connected.
@Issue: https://github.com/thorvg/thorvg/issues/3231
The differences resulted from discrepancies between
the engines in applying equality or inequality signs
and in using different precision levels when determining
the dash remainder when transitioning to a new path
command.
@Issue: https://github.com/thorvg/thorvg/issues/3265
Support the bindings to be more integrable with a system's coherent memory management.
Pleaes note that thorvg now only allow the desinated memory allocators here:
malloc -> tvg::malloc
calloc -> tvg::calloc
realloc -> tvg::realloc
free -> tvg::free
issue: https://github.com/thorvg/thorvg/issues/2652
The sw_engine, when determining the outline, converts
floats to ints by multiplying them x64, resulting in
a comparison precision of 1/64 = 0.015625.
Both gl_engine and wg_engine operate on floats. Before
adding a closing point to a shape, they performed a comparison
to check if the point differed from the starting point:
- wg: with a precision of 1e-3 (using length2, i.e., eps = 1e-6
- gl: used direct == comparison.
Now, consistency has been ensured by introducing a comparison
precision of 1/64 in both wg_engine and gl_engine.
@issue: https://github.com/thorvg/thorvg/issues/2799
@issue: https://github.com/thorvg/thorvg/issues/3235
RenderMethod effects methods would have changes:
+ update() //update the effects if any
- prepare() -> region() //update the effect drawing region
- effect() -> render() //draw the effect
GlRenderTarget contains framebuffer and render target objects,
these GPU resources need to be released before reusing the structure and calling init with the new size.
Ensure they do not terminate prematurely for paths
with a step of 0 or exceptionally small values
when a valid stroke-width is present.
In my opinion, the optimal approach was to separate vertex generation
into dedicated methods: strokeRoundPoint and strokeSquarePoint.
My update supports two different stroke-cap styles.
I have also tested it with various files (JSON, SVG)
as well as a small example application similar
to the one included in the previous pull request (#3066).
issue: https://github.com/thorvg/thorvg/issues/3065
ThorVG pImpl idiom caused internal data to be scattered
across hierarchical classes. This refactoring consolidates
the data by inheriting pImpl internally, reducing memory
allocation counts and eliminating unnecessary strategy methods.
