certain systems, may not support file I/O operations.
ThorVG should provide users with an option to configure
builds according to their requirements.
This ensures that file I/O calls are avoided,
preventing potential crashes.
Please use the meson '-Dfile=true/false' option for this.
Please note that "THORVG_FILE_IO_SUPPORT" might be expected
for your thorvg manual build.
issue: https://github.com/thorvg/thorvg/issues/3008
enhance decoding efficiency by determining the desired canvas format
during image loading. This allows loaders to preemptively decode
the image in the specified format, to not convert the format again.
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
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.
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
../src/loaders/external_png/tvgPngLoader.cpp(110): warning C4244: '=': conversion from 'float' to 'uint32_t', possible loss of data
../src/loaders/external_png/tvgPngLoader.cpp(111): warning C4244: '=': conversion from 'float' to 'uint32_t', possible loss of data
../src/loaders/external_png/tvgPngLoader.cpp(112): warning C4244: '=': conversion from 'float' to 'uint32_t', possible loss of data
Since the color space is set at the time of specifying the target buffer of the canvas,
there is no way to know the color space when the picture is loaded.
So, check the color space applied to SwCanvas at the time of reload()
and change the color space.
There is an issue of BGR color space support for each loader.
The external_jpg loader resets the TJPF color space and calls read() to get a new buffer.
In the case of external_png, we need to change the color value directly
because it have to start over from begin_read_*.
This solution can affect performance as much as it access again image buffer
that have already been `read()` done. However, this only happens once.
Previously, translucent png images are not displayed properly
due to alpha channels premultiplication.
This patch implements that missing part to support it properly
by introducing the Surface data between canvas engine & rasterizer
@Issue: https://github.com/Samsung/thorvg/issues/655
This reverts commit cd5116b053.
Ah this breaks the Stress example due to Picture::duplicate() is not available...
Need to consider and come back again.
* common: added colorSpace() function
This patch introduces colorSpace() function for SW and GL engine.
* infra: change LoadModule:read() into LoadModule:read(uint32_t colorspace)
This patch changes LoadModule:read() into LoadModule:read(uint32_t colorspace)
* picture: implement passing colorspace into loader
This patch implements passing colorspace into loaders.
Loader->read is now called on the first update.
* external_jpg_loader: support colorspaces
* external_png_loader: support colorspaces
This patch has 2 purposes,
1. revise the loaders infrastructure to support both static/external linking loaders.
2. add a template for static jpg/png loaders after external jpg/png.
Our default loaders prefer static linking, external loaders are only available
when dependent libraries on the build system are found.
You might wonder why we have the external loaders together,
they might be faster than static loaders since the popular libraries are likely to be well maintained,
fine-grained optimized.
Thus in this patch, meson tries to apply the external loaders first
then see if the dependencies were found or not,
if it's failed, it turns to the default static loaders.
Next this patch, we need the contribution for actual static jpg/png loaders implementation.
@Issue: https://github.com/Samsung/thorvg/issues/594
