- introduced a blending factor to control the mix between the original color and the tritone effect.
- improved Lottie compliance with this enhancement.
- implemented the spec by all engines
CAPI:
* Tvg_Result tvg_scene_push_effect_tritone(Tvg_Paint* scene, int shadow_r, int shadow_g, int shadow_b, int midtone_r, int midtone_g, int midtone_b, int highlight_r, int highlight_g, int highlight_b);
-> TVG_API Tvg_Result tvg_scene_push_effect_tritone(Tvg_Paint* scene, int shadow_r, int shadow_g, int shadow_b, int midtone_r, int midtone_g, int midtone_b, int highlight_r, int highlight_g, int highlight_b, int blend);
- corrected the reversed black/white intensity multiplication.
- made a minor adjustment to the luma equation.
- updated and aligned the API documentation accordingly.
added new functionality for bezier curves:
1. generate bezier curve as an arc
2. estimate the number of points for optimal tessellation
3. check that bezier curve is close to a straight line
This functionality is useful for gl/wg renderers
This change ensures at the api level that if the focal
point lies outside the end circle, it is projected onto
the edge of the end circle.
Additionally, if the start circle does not fully fit
inside the end circle (after possible repositioning), its
radius is reduced accordingly.
The modification aligns with the SVG 1.1 standard (for fr = 0).
Cases with fr > 0 are not covered by the SVG 1.1, and edge
cases have been handled here to avoid numerical issues.
Note:
This update replaces previous behavior where gl handled
the SVG 2.0 standard.
The API allows now values <= 0 for dashes and gaps. Negative values
are treated as zero. The exception is when all provided values
are <= 0, in which case the dash is ignored.
This fixes the issue when dash = 0 was provided for strokes with round
or butt caps - the dot was not drawn, even though it should have been.
docs: the strokeDash API behavior's clarification for odd numbers
of values in dashPattern and refinement of the accepted values.
Partial Rendering refers to a rendering technique where
only a portion of the scene or screen is updated, rather
than redrawing the entire output. It is commonly used as
a performance optimization strategy, focusing on redrawing
only the regions that have changed, often called dirty regions.
This introduces RenderDirtyRegion, which assists
in collecting a compact dirty region from render tasks.
To efficient data-processing, this divide the screen region
with a designated size of partition and handles the partitl rendering
computation with a divide-conquer metholodgy.
Each backend can utilize this class to support efficient partial rendering.
This is implemented using a Line Sweep and Subdivision Merging O(NlogN).
The basic per-frame workflow is as follows:
0. RenderDirtyRegion::init() //set the screen size to properly partition the regions
1. RenderDirtyRegion::prepare() //Call this in Renderer::preRender().
2. RenderDirtyRegion::add() //Add all dirty paints for the frame before rendering.
3. RenderDirtyRegion::commit() //Generate the partial rendering region list before rendering.
4. RenderDirtyRegion::partition() //Get a certian partition
5. RenderDirtyRegion::get() //Retrieve the current dirty region list of a partition and use it when drawing paints.
6. RenderDirtyRegion::clear() //Reset the state.
RenderMethod introduced for 2 utilities for paritial renderings
1. RenderMethod::damage() //add a force dirty region, especially useful for scene effects
2. RenderMethod::partial() //toggle the partial rendering feature
issue: https://github.com/thorvg/thorvg/issues/1747
The clear flag specified in Canvas::draw is ignored when set to false,
since GlRenderer::mClearBuffer is never explicitly reset to false.
This commit ensures that mClearBuffer is reset to its default (false)
after being used, so that the clear operation behaves correctly per frame.
- Issue: #1779
redefiend properties so that min/max are prioritized,
as they are accessed more frequently than pos/size
during rendering calculations.
also introduced miscellaneous functions to improve usability.
Added drawing exceptions when target is not properly ready.
Now, Canvas::update() Canvas::draw() will return InsufficientCondition
if the target has not been set beforehand.
no any 3rd-party libs, such as glfw or glad did not used
support windows, linux, macos and emsdk
only the actually used set of functions are loaded
Co-Authored-By: Sergii Liebodkin <sergii@lottiefiles.com>
Co-Authored-BY: Hermet Park <hermet@lottiefiles.com>
issue: https://github.com/thorvg/thorvg/issues/2453
- C-style strings provide consistent binary interface for FFI
- Reduces potential issues where standard library is limited (e.g., WebAssembly, embedded systems)
Simplified parameters and ensured proper backend engine
initialization by using reference checking through canvas
instances.
C++ API Modification:
- Result Initializer::init(uint32_t threads, CanvasEngine engine)
-> Result Initializer::init(uint32_t threads)
- Result Initializer::term(CanvasEngine engine)
-> Result Initializer::term()
C API Modification:
- Tvg_Result tvg_engine_init(Tvg_Engine engine_method, unsigned threads)
-> Tvg_Result tvg_engine_init(unsigned threads);
- Tvg_Result tvg_engine_term(Tvg_Engine engine_method)
-> Tvg_Result tvg_engine_term()
issue: https://github.com/thorvg/thorvg/issues/3116
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
