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
I've added new parameter, const string& resourcePath, to load external image on lottie.
Result load(const char* data, uint32_t size, const string& mimeType, bool copy, const string& resourcePath)
Note: tvgLoadModule will have new overrided method `open`, not to effect to other changes except animation.
Issue: #1793
Set colorspace to ABGR when colortype of lodepng is LCT_RGBA.
Since an image without an alpha channel becomes an ARGB colorspace with LCT_RGB,
it is the same as the default colorspace.
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
Copied only necessary decoding functions from the lodepng opensource.
See: https://lodev.org/lodepng/
additional changes:
- disabled crc for the optimal size.
- converted the format bgr -> rgb for our png example.
Still we don't have a concrete idea for the image formats,
We should fix the converting methods between bgra <-> rgba.
@Issue: https://github.com/Samsung/thorvg/issues/594
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
Bitmap based pictures doesn't need the viewbox,
LoaderModule should delegate the viewbox to the derived classes which
having vector-based image loaders such as svg, tvg.
In that case, paint resizing can be performed by the loaders by own
policy.
