replaced 32-bit operations with 8-bit operations for masking buffers.
We might need a grasycale image support for applying 1-byte channel masking input(Picture).
Some of masking implementation are disabled by this reason.
Also, I don't expecct it's necessary for the thorvg now.
Corrected subtract/intersect masking behaviors that were inaccurately functioning
within chain-masking.
This also helps to enhance the masking performance by reducing the
masking region when applying subtract/intersect.
@Issue: https://github.com/thorvg/thorvg/issues/1606
[29/73] Compiling C++ object src/libthorvg.a.p/lib_sw_engine_tvgSwStroke.cpp.obj
../src/lib/sw_engine/tvgSwStroke.cpp(258): warning C4244: 'argument': conversion from 'float' to 'int64_t', possible loss of data
[32/73] Compiling C++ object src/libthorvg.a.p/lib_sw_engine_tvgSwRaster.cpp.obj
../src/lib/sw_engine/tvgSwRaster.cpp(259): warning C4244: 'initializing': conversion from 'float' to 'uint32_t', possible loss of data
../src/lib/sw_engine/tvgSwRaster.cpp(260): warning C4244: 'initializing': conversion from 'float' to 'uint32_t', possible loss of data
Renamed internal methods; the name 'RGBA' is sometimes confusing
because the channel composition does not accurately reflect it.
Therefore, it should be removed or replaced with 'Pixel'.
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>
Reduce duplicated masking raster code by replacing with c++ templates
this change does not noticeably impact performance (< error bound).
Binary Size diff: 218379 -> 217851 (-0.5kb)
Reduce excessive gradient filling code duplication by employing C++ template method.
This change does not affect performance or binary size adversely.
Binary Size Diff: 223399 -> 222693 (-706)
Compact blending instructions by distinquish the
shape & images. since we gurantee the shape color is
premultiplied alpha.
As a result, this enhanced performance by 0.002s in examples/Performance
on my local machine.
This also contains code cleanup chores.
The CompositeMethod now includes the newly supported InvLumaMask option:
The source pixels are converted to grayscale (luma values),
and the complement of the target's pixels is alpha blended.
As a result, only the part of the source where the grayscale
is not covered by the target is visible.
@APIs: CompositeMethod::InvLumaMask
@Example: examples/InvLumaMasking.cpp
@Issue: https://github.com/thorvg/thorvg/issues/404
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
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.
Introduced CompositeMethod::LumaMask that converts the source pixels to the
grayscale (luma value) before alpha blending. Thanks to it, mask works more like
typical mask in graphics editor software.
Grayscale is calculated with weighted method:
(0.0721*B + 0.7154*G + 0.2125*R) * A
Introduced surface->blender.lumaValue function
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
The x and y of spans cannot be negative
because they are specified as coordinates inside the buffer.
Change the type to fix warnings and potential problems
that occur in conversion between int16_t and uint32_t.
apply fast track to fast up the image rasterization.
only shifted image doesn't need to have the matrix-transform computation,
we can avoid it by just shifting offset xy by simple caculating.
@Issue: https://github.com/Samsung/thorvg/issues/206
