Both functions implemented using 128-bit registers.
avxRasterTranslucentRect is around 5 times faster than cRasterTranslucentRect (i7-8700 CPU - Coffe Lake)
Changes:
Added neonRasterTranslucentRect implementation. Rendering was tested on
32 lottie fiels. Without neon ~ 18.1 FPS was measured. With neon ~ 20.1
FPS was measured.
Separate simd implementation by files to maintain them easier.
Now we have avx, c, neon version implementation base,
we can add implementations to them.
Changes:
- Prepare neon verison of ALPHA_BLEND API.
- Use ALPHA_BLEND_NEON in _translucentRle
Notes:
- _translucentRle with neon support reduces execution time of this
function ~ 300 % (measured on uint32_t 400 x 400 buffer).
- API was tested on ARMv7l device with GCC 9.2 based toolchain. Results
on other devices could be different.
* Apply bilinear interpolation to images
Apply bilinear interpolation when drawing images with transformation
If the mapped coordinate value is a floating point value,
bilinear interpolation is performed using adjacent pixel values.
Interpolation is not performed in cases when the color values to beinterpolated
are the same or scale down case.
We can replace the system logger method by changing single line print source in common,
This also helps to remove the THORVG_LOG_ENABLED macro from each use-cases.
TVGLOG(): To print the hint & tip messages for users.
TVGERR(): To print the error message for debugging.
@Issues: https://github.com/Samsung/thorvg/issues/36
The translucent rastering function is split into 3 other (instead of if/else statement).
An additional function is introduced to decide which one of the 3 should be called.
This refactoring is done to preserve the convention used for all other rastering functs.
The translucent rastering function is split into 3 other (instead of if/else statement).
An additional function is introduced to decide which one of the 3 should be called.
This refactoring is done to preserve the convention used for all other rastering functs.
The translucent rastering function is split into 3 other (instead of if/else statement).
An additional function is introduced to decide which one of the 3 should be called.
This refactoring is done to preserve the convention used for all other rastering functs.
The translucent rastering function is split into 3 other (instead of if/else statement).
An additional function is introduced to decide which one of the 3 should be called.
This refactoring is done to preserve the convention used for all other rastering functs.
The cases with gradient shapes with composition are handled
in the same function as gradint shapes with opacity < 255.
Parts of the code from _rasterOpaque... grad functions moved to
_rasterTranslucent... grad functions.
The cases when composition was applied were handled only for AlphaMask and
InvAlphaMask. When opacity value was to be < 255, there was no code
to handle this.
In the fillFetchLinear function the offset parameter was removed.
The destination address may be shifted directly in the dst parameter,
it doesn't need to be passed separately.
previously alpha multiplying operation doesn't have perfect precision,
could loss 1 pixel since it divides 255 values by 256.
This improved operation comply with both precision & performance.
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
The alpha value calculation pulled out outside the inner loop
to reduce the number of unnecessary operations.
Added local variables to reduce the number of costly
multiplications performed in a loop.
* sw_engine: adding a gradient as a stroke feature
Similarly as a shape may have a gradient fill so can the stroke.
* Capi: adding APIs for a gradient stroke
Co-authored-by: Hermet Park <hermetpark@gmail.com>
added a routine that draw non-transformed translucent image.
composition images will use this routine to draw faster.
Also added optimization point comments in raster image.
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.
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
Move the prepare stage of shape & stroking composition stage to a separate function
this returns SwImage to use in composite stage.
Also clear partial region buffer since we know composition area.
* sw_engine raster: code refactoring & optimize code.
1. move the computation out of rolling if possible.
2. renamed internal variables & function prototypes.
