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
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
As there are multiple types of painting tasks,
the clip() interface has been newly designed to handle clipping behavior
according to each task's role when requested."
Now Scene clipper could implement clipping behavior on it.
Logging tags are marked with the corresponding
log type color, the file and the line information
in gray, and the message content in the default
color.
@Issue: https://github.com/thorvg/thorvg/issues/1351
Revise the logic to avoid potential blocking of the main thread.
Move the clippers job completion to worker-threads to prevent main thread blocks
and enhance maximum parallelization efficiency.
We have an incorrect value comparison when the stroke corner center
is adjusted. All coordinates in the stroke raster have been scaled by
the given values (sx, sy), while the stroke width remains at its
original size due to it not being clear how it should be scaled.
This brings wierd rendering results at times. Now fix it.
@Issue: https://github.com/thorvg/thorvg/issues/1336
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.
../src/lib/gl_engine/tvgGlRenderer.cpp: In member function ‘virtual bool GlRenderer::renderShape(tvg::RenderData)’:
../src/lib/gl_engine/tvgGlRenderer.cpp:171:30: warning: ‘a’ may be used uninitialized in this function [-Wmaybe-uninitialized]
171 | drawPrimitive(*sdata, r, g, b, a, i, RenderUpdateFlag::Stroke);
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/lib/gl_engine/tvgGlRenderer.cpp:171:30: warning: ‘b’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/lib/gl_engine/tvgGlRenderer.cpp:171:30: warning: ‘g’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/lib/gl_engine/tvgGlRenderer.cpp:171:30: warning: ‘r’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/lib/gl_engine/tvgGlRenderer.cpp: In member function ‘virtual void* GlRenderer::prepare(const tvg::RenderShape&, tvg::RenderData, const tvg::RenderTransform*, uint32_t, tvg::Array<void*>&, tvg::RenderUpdateFlag, bool)’:
../src/lib/gl_engine/tvgGlRenderer.cpp:215:21: warning: ‘alphaS’ may be used uninitialized in this function [-Wmaybe-uninitialized]
215 | uint8_t alphaF, alphaS;
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.
According to the svg specs clip's fill and opacity
should be ignored. Till now setting the alpha/opacity
value to zero resulted in the shape's rendering abort.
@Issue: https://github.com/Samsung/thorvg/issues/1192
