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
