Until now, only stroke trimming was possible,
but the Lottie standard requires support for
trimming both (if present), stroke and fill.
This commit changes the API behavior.
@Issue: https://github.com/thorvg/thorvg/issues/3118
A JavaScript code line may return undefined, but this should not be treated as an error.
For example, consider the following two lines of code:
- `var $bm_rt = 30` (Statement) → result: `undefined`
- `$bm_rt = 30` (Expression) → result: `30`
Both lines execute the same operation, but the JavaScript interpreter (REPL JS) evaluates them differently.
Therefore, an evaluation result of undefined should not be blocked, as it does not indicate a failed code execution.
Load default font data during initialization. This enables the web system to load when the system font cannot be used.
Added a binary-embeddable font file resource. This file has quite small size while containing essential glyphs.
- DM Sans: https://github.com/googlefonts/dm-fonts
Before the C++ compiler couldn't decide the template of std::min (that happen if `int` type is not an `int32_t`), so explicitly changing all types to int32_t fixes this.
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
Manage the global buffer memory for vertex and indexed vertex buffers,
increase the memory size incrementally twice by default and reduce
the default buffer size, which is not suitable for typical scenarios.
This could reduce the a bit stack memory usage and improve
the portability across systems where has the stack memory
limitation and potentially gaining performance enhancement
by avoiding brutal stack memory usage at the many function calls.
added the internal functions:
- WgVertexBuffer* mpoolReqVertexBuffer(float scale = 1.0f);
- WgIndexedVertexBuffer* mpoolReqIndexedVertexBuffer(float scale = 1.0f);
- void mpoolRetVertexBuffer(WgVertexBuffer* buffer);
- void mpoolRetIndexedVertexBuffer(WgIndexedVertexBuffer* buffer);
issue: https://github.com/thorvg/thorvg/issues/3159
- Changed optimization flags to -Oz, reducing the binary size by 120KB.
- Applied wasm-opt convergence as a post-process to ensure the minimum possible size with the given optimization flag.
In cases where the fill was changed while the stroke existed
but remained unchanged, the stroke would disappear because it
was being reset during the shape preparing (shapeReset).
Fixed by disabling the reset of stroke rle from shape reseting.
Also the shape should be prepared not only when the RenderUpdateFlag
is set to Color, but also when it is set to Gradient.
@Issue: https://github.com/thorvg/thorvg/issues/3237
For an odd number of dash/gap segments, the offset was
handled incorrectly because the non-doubled count of
dashes and gaps was used.
Additionally, in ddcbbf7, an error was introduced by
overlooking the fact that the offset can shift the dash
pattern in such a way that the first segment of the dashed
line becomes a gap.
Until now lottie loader supported only a single
dash-gap pair, and only the case where only the dash
was provided was handled correctly. When both values
were provided, the gap was incorrectly increased by
the dash value. If more values were supplied, only
the last pair was considered.
@Issue: https://github.com/thorvg/thorvg/issues/3191
This eliminates the jerryscript features
which are unlikely to be used by thorvg.
- JERRY_LINE_INFO
- JERRY_PROMISE_CALLBACK
- JERRY_FUNCTION_TO_STRING
- JERRY_MEM_GC_BEFORE_EACH_ALLOC
- JERRY_CPOINTER_32_BIT
- JERRY_REGEXP_STRICT_MODE
We have improved the functionality to manage the memory pool safely,
by figuring out the current working threads. Users no longer need to
manually configure memory pool management, and the related APIs
have been removed.
API Removals:
- Result SwCanvas::mempool(MempoolPolicy policy)
- enum SwCanvas::MempoolPolicy
- Tvg_Result tvg_swcanvas_set_mempool(Tvg_Canvas* canvas, Tvg_Mempool_Policy policy)
- enum Tvg_Mempool_Policy
issue: https://github.com/thorvg/thorvg/issues/3116
Bug introduced as part of a7e7bbc.
After recalculating begin and end to the 0-1 range, an extra
check was added to handle cases when begin is very close to end.
However, this was a bad approach since, even for very close values,
their relationship remains important. What should have been
done in the mentioned commit is properly handling the case
begin == end, which was incorrectly treated as trimming from begin
to end. Instead, it should be handled as trimming from begin to
1.0 and from 0.0 to end.
@Issue: https://github.com/thorvg/thorvg/issues/3204
- In cases where the begin and end values of trimming did not
result in trimming (end - begin > 1), trimming was ignored.
However, when the stroke is also dashed, this case affects
the shift of the point where the first dash becomes visible.
- Trimming that passes through the curve's start point (like -0.1:0.1)
requires passing through the curve twice. The points obtained from
both passes must be joined - visible when dashing
Cases for simultaneous = true have been handled.
@Issue: https://github.com/thorvg/thorvg/issues/3192
