Write the pixels per 64-bit data.
This optimization can potentially double the performance in the best case scenario.
It's visually noticeable, especially when the resolution is sufficiently large.
@Issue: https://github.com/thorvg/thorvg/issues/1471
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 duplicated image raster code between scaler approaches.
Although this allows for a function call per pixel,
this change does not noticeably impact performance (< error bound).
Binary Size diff: 222541 -> 218379 (-4kb)
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)
Unify textmap methods that are overly duplicated with each other.
Still trying to simplifying raster code so that thorvg could introduce
the a bunch of masking method code nicely.
This reduces the size like: 214773 -> 212843 (-2kb)
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
There are two branches for completing stroke composition between the canvas and sw_engine.
It is necessary to centralize the task on the canvas engine side so that
we can maintain the logic without confusion.
There is a report of the thread sanitizer.
It could be a false-positive as far as I reviewed,
but we hate to be bothered by it. So let's revert it.
@Issue: https://github.com/thorvg/thorvg/issues/1409
One more regression bug by afea40a947
As tasks will now be triggered by other tasks on the worker threads,
the designated memory pool data (outline) for each thread should be
reset before moving on to other tasks.
@Issue: https://github.com/thorvg/thorvg/issues/1409
The previous memory pool was being shared by both the main and first threads,
which could lead to corruption if any threading changes occurred.
@Issue: https://github.com/thorvg/thorvg/issues/1370
The new api is introduced to handle the rendering
order of a stroke and a fill. By default fill is
rendered as the first one, stroke as the second
one. This order can be reversed by calling
order(true).
@Issue: https://github.com/thorvg/thorvg/issues/1340
