The blending feature allows user to combine colors to create visually appealing effects,
including transparency, lighting, shading, and color mixing, among others.
Its process involves the combination of colors or images from the source paint object
with the destination (the lower layer image) using blending operations.
The blending operation is determined by the chosen @p BlendMethod,
which specifies how the colors or images are combined.
@APIs:
- enum class BlendMethod::Normal, Add, Screen, Multiply, Overlay, Lighten, Difference, Exclusion, SrcOver, Darken, Lighten, ColorDodge, ColorBurn
- BlendMethod Paint::blend() const noexcept;
- Result Paint::blend(BlendMethod method) const noexcept;
@Issue: https://github.com/thorvg/thorvg/issues/307
Co-authored-by: Peter Vullings <peter@projectitis.com>
Co-authored-by: Hermet Park <hermetpark@lottiefiles.com>
Introduced SceneTask, it implements scene clippath behavior
by merging RLE of the scene children render data on any running thread.
Co-authored-by: Michal Szczecinski <m.szczecinsk@partner.samsung.com>
@Issue: https://github.com/thorvg/thorvg/issues/524
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.
re-design the shape data structure so that render backends
are able to access them directly.
This also let us remove tvgShape member data from the Shape::Impl.
To achieve this, migrate shape/stroke/path
from the canvas interface to the render interface.
If a paint is used as a clipper, it must be determined in the paint behavior.
Propagate its decision to the immediate derived classes so that
not only shapes but also scenes must be dealt as a clipper properly.
This revised this change 0de3872be3
for better a solution.
The implementation of the virtual prepare() method is different from that of RenderMethod.
from that of RenderMethod, so the compilation fails. This modification solves the problem.
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
If ClipPath is a singular rectangle,
we don't need to apply this to all children nodes to adjust rle span regions.
Rather than its regular sequence,
we can adjust render region as merging viewport that is introduced internally,
All in all,
If a Paint has a single ClipPath that is Rectangle,
it sets viewport with Rectangle area that viewport is applied to
raster engine to cut off the rendering boundary.
In the normal case it brings trivial effects.
but when use SVGs which has a viewbox, it could increase the performance
up to 10% (profiled with 200 svgs rendering at the same time)
Note that, this won't be applied if the Paint has affine or rotation transform.
@Issues: 294
Renamed internal interfaces.
We need both blender & compositor interfaces.
Renamed SwCompositor -> SwBlender which is for pixel joining methods.
Added (SwCompositor, Compositor) which is designed for compositing images.
Splited out ClipPath routine from other pixel compositions'
since yet it's unlikely compatible...
Also revise internal engine interfaces to be simpler.
This is a step forward to enhance masking feature.
Introduce RendererMethod::renderRegion() to return acutal drawing region info.
That is used by scene composition to composite actual partial drawing region
for better performance.
@Issues: 173
Apply tvg Array instead of std::vector
Also Fixed to compList in update() to passed by reference, not copying.
Also Fixed Composition Target memory leak
Here is the binary size result:
[libthorvg.so] 1785376 >> 1607416
[text] 121255 >> 118277
[data] 7792 >> 7736
[dec] 129119 >> 126085
this is an additional enhancement of af8c278c5e
Now scene opacity composition is supported.
Also, this implementaion fixes an incorrect scene bounding box computation.
Plus, adding stroking feathering to shape bounding box size.
we introduced shared memory pool for avoiding reallocate memory
while it process the stroke outlines, It experimentally increase
the outline data if we use the allocated memory for multiples shape strokes,
we don't need to alloc/free memory during the process.
This shared outline memory is allocated for threads count
so that we don't interrupt memory access during the tasks.
@Issues: 75
We introduced separate opacity interface to adjust alpha value by paint.
This opacity will affect to whole paint image if paint is a group of paints.
Also, this opacity is to multipy with fill/stroke alpha values.
This means if the opacity is valid, the paint might deal with a composition step,
which is very expensive due to additional rendering step.
One tip is, if you want to toggle on/off for a certian paint,
you can set opacity to 255 or 0.
@API Additions:
Result Paint::opacity(uint8_t o) noexcept;
uint8_t Paint::opacity() const noexcept;
@Examples: examples/Opacity
@Issues: 94
common sw_engine: Implement ClipPath feature
Paint object can composite by using composite API.
ClipPath composite is clipping by path unit of paint.
The following cases are supported.
Shape->composite(Shape);
Scene->composite(Shape);
Picture->composite(Shape);
Add enum
enum CompMethod { None = 0, ClipPath };
Add APIs
Result composite(std::unique_ptr<Paint> comp, CompMethod method) const noexcept;
* Example: Added testClipPath
previous implementation didn't consider multiple canvases,
multiple canvas shared one renderer engine that brought corrupted contexts.
Thus, each canvas instances should have designated renderer engine instances.
Now fixed.
We prefer to build up a tiny compact engine at memory rather than compatibility,
this engine is not considerd for end-users but designed for middle-level framework
and some low-level users.
Thus, we won't consider 64bits data size,
use explicit 32 bits data until coming next upgrade...
Change-Id: I0704d5f1e0eb909cccc10922bc5972e115fbbcc0
Paint supports translate, rotate, scale functions for transformation
The origin of these transformation is center of the paint,
thus you have to consider the center-aligned vertices if you'd like to use
these transformation functions.
This policy has been considered for scene transformation.
Change-Id: I78b63d7965faec0ec5b9a98a7776993744534b54
Come to think of it, this optimized method is not so useful,
it could just bring the user misunderstanding and
not to efficient as I expected in the most cases.
So, changed policy for transformation behaviors.
it keeps the properties as others but leaves it to the backend implementation.
Plus, this change contains the correct RenderUpdateFlag.
You can refer the flag in the backend to figure out which kinds of properites has been updated
Change-Id: Ibe0494712598a8161950b9ae2e22ac45bed1c47b
