dispose of the resources at the end of the paint deletion.
This will help retain the resources of the retained paints
and reuse them after reconstructing the next scene.
This update fixes an issue where duplicated overlapping curves/lines,
when introduced as a single line.
That case overlapping command operation is take account for
the trim path's path-building process.
We now skip such cases to ensure the trim path functions correctly.
issue: https://github.com/thorvg/thorvg/issues/1939
resolved a corner case where assets were being attached
multiple times during scene building. This issue was causing
a significant performence drop in image animation
in certain scenarios.
adjusted the starting position of the rounded rectangle to 90 degrees
to ensure compatibility with the Lottie trim path effect.
This modification follows the earlier circle correction applied to the rectangle.
issue: https://github.com/thorvg/thorvg/issues/1933
The compositor memory is likely to be reused in the next frame.
To enhance performance, it is advisable to retain this memory by default.
We may consider introducing a cache policy interface in the Initializer.
This would allow users to manage the Canvas memory more effectively.
Anyhow, this improves the Lottie example performance by 10%
Adjust the sampling count according to the scale ratio.
This significantly improves performance
while making it hard to recognize any loss in image quality.
Lottie example performance has improved by 15%.
Some systems such as micro-processor might not support
the thread feature on the system.
Enhance the portability by compiling the thorvg with toggling the
threading depepdency through the build option.
For this, thorvg newly introduced the internal Key/ScopedLock abstraction
for transparent thread-locking dependnecy.
To turn off the thread feature, please use the next build option:
$meson setup build -Dthreads=false ...
Note that, the thread feature is enabled in default.
Turning off the thread feature could reduce the binary size by 7kb.
issue: https://github.com/thorvg/thorvg/issues/1900
the bug was introduced in 9bf8bb018d.
Migrated the circle commands to the rectangle, which is currently necessary.
Retained the previous circle commands for backward compatibility.
Adjusted the path's start point to 90 degrees
to align the origin consistently with other path commands.
No compatibility issue, this only could affect the trimpath effects.
Introduced a dedicated mutex for each surface instance
to ensure safe sharing between the loader, renderer, and engine.
This enhancement allows for secure modification and access to bitmap data,
addressing potential concurrency issues.
Multiple Picture instances can now safely share a single loader instance,
optimizing performance.
This change builds upon the previous Loader Cache improvements:
ff6ea4b6c4
../src/renderer/gl_engine/tvgGlRenderer.cpp:450:24: warning: comparison of integer expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Wsign-compare]
450 | for (auto i = 0; i < mComposePool.count; i++) {
|
Applied 2 more internal LoaderMgr interfaces for
gobally manage the font data resources.
The next function is introduced for lookup the existing loader
with the font name (key)
- static LoaderMgr::LoadModule* loader(const char* key);
The next function is introduced to free the existing loader
with the loader source(file path)
- static bool retrieve(const string& path);
Additionally implements the base loader to bind the ttf loader.
ttf is an industry standard format that is the most widely used
in the products. Now thorvg supports the basic features of
the font to supplement the text drawing.
The implementation is followed the ttf spec,
the covered features are:
- horizontal layouting with kerning.
- utf8 -> utf32 converted glyph drawing.
To use the feature, please enable ttf loader:
$meson -Dloaders="ttf_beta, ..."
@Issue: https://github.com/thorvg/thorvg/issues/969
We are introducing the FontLoader, which slightly differs
from the ImageLoader in terms of features. To adequately
support both, we have separated the loader functionalities
into FontLoader and ImageLoader. This allows us to optimally
adapt the LoadModule for each case.
Before the current changes, all surfaces were painted using a full-screen overlay, no matter how large the object was rendered. This approach is redundant and required reorganization. At the moment, all objects are rendered using an overlay equal to the box of the object itself, which reduces the cost of filling the surface.
Also surfaces and images were divided into different entities, which reduces the pressure on memory.
Also geometry data for rendering and geometry data for calculations in system memory were logically separated.
For further development of features, we need to create off-screen buffers that will allow us to implement functionality related to composition and blending, as well as for loading data to system memory from the framebuffer. Separating the framebuffer into a separate entity allows you to create several instances of them, switch between them, and blend them according to given rules.
For current time we have only a single render target instance, that have a handle to drawing into surface surface, like a native window.
New approach allows:
- offscreen rendering
- render pass handling
- switching between render targets
- ability to render images, strokes and shapes into independent render targets
since the framebuffer will draw back to parent RenderPass, it can be
reused in next compose rendering.
So instead of create framebuffer every time when beginCompose is called, we
trying to reuse the framebuffer created before in the same stack level
The magic number kappa (0.552284), which is associated with the bezier curve,
has been introduced. This formula is supposed to be applied to the rounded corners
of the rectangle to ensure consistent drawing results.
Issue: https://github.com/thorvg/thorvg/issues/1824
The loader cache is applied to conserve memory.
If the input data is already present in loaders,
the loader cache will promptly return the active loader.
This results in a lot of memory savings for the duplicated resources.
binary diff: -400 bytes
