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.
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.
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
If vv goes out of buffer, it can cause potential memory problems.
Therefore, an `if condition` is added so that it does not exceed the height of the image.
This is temporary fix.
Test)
meson -Db_sanitize=address,undefined -Dexamples=true . build
$ ./build/src/examples/Texmap
==6298==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f37fd6c2180 at pc 0x7f380d884599 bp 0x7fffb02b2db0 sp 0x7fffb02b2da0
READ of size 4 at 0x7f37fd6c2180 thread T0
#0 0x7f380d884598 in _rasterPolygonImageSegment ../src/lib/sw_engine/tvgSwRasterTexmapInternal.h:107
#1 0x7f380d887694 in _rasterPolygonImage ../src/lib/sw_engine/tvgSwRasterTexmap.h:271
#2 0x7f380d88a598 in _rasterTexmapPolygonMesh ../src/lib/sw_engine/tvgSwRasterTexmap.h:639
#3 0x7f380d89828d in _transformedRGBAImageMesh ../src/lib/sw_engine/tvgSwRaster.cpp:701
#4 0x7f380d89828d in rasterImageMesh(SwSurface*, SwImage*, tvg::Polygon const*, unsigned int, tvg::Matrix const*, SwBBox const&, unsigned int) ../src/lib/sw_engine/tvgSwRaster.cpp:1585
#5 0x7f380d89bf16 in tvg::SwRenderer::renderImageMesh(void*) ../src/lib/sw_engine/tvgSwRenderer.cpp:369
#6 0x7f380d830e7e in tvg::Paint::Impl::render(tvg::RenderMethod&) ../src/lib/tvgPaint.cpp:178
#7 0x7f380d823bd2 in tvg::Canvas::Impl::draw() (/home/junsu/dev/os/thorvg/build/src/examples/../libthorvg.so.0+0x265bd2)
#8 0x7f380d821e79 in tvg::Canvas::draw() ../src/lib/tvgCanvas.cpp:60
#9 0x557d07b2d5b6 in drawSwView(void*, _Eo_Opaque*) ../src/examples/Texmap.cpp:103
#10 0x7f380cb7d2aa in evas_process_dirty_pixels ../src/lib/evas/canvas/evas_object_image.c:1894
#11 0x7f380cb7d2aa in _evas_image_pixels_get ../src/lib/evas/canvas/evas_object_image.c:2318
#12 0x7f380cb7d85e in _evas_image_render ../src/lib/evas/canvas/evas_object_image.c:2468
#13 0x7f380cb7ea0c in evas_object_image_render ../src/lib/evas/canvas/evas_object_image.c:2271
#14 0x7f380cbe51db in evas_render_mapped ../src/lib/evas/canvas/evas_render.c:2290
#15 0x7f380cbe6f15 in evas_render_updates_internal_loop ../src/lib/evas/canvas/evas_render.c:3158
#16 0x7f380cbe9912 in evas_render_updates_internal ../src/lib/evas/canvas/evas_render.c:3631
#17 0x7f380cbeb31c in _evas_canvas_render_async ../src/lib/evas/canvas/evas_render.c:4094
#18 0x7f380cb6634a in evas_canvas_render_async ../src/lib/evas/canvas/evas_canvas_eo.c:168
#19 0x7f380cb6fce5 in evas_render_async ../src/lib/evas/canvas/evas_canvas_eo.legacy.c:179
#20 0x7f37f3a81555 in _ecore_evas_x_render ../src/modules/ecore_evas/engines/x/ecore_evas_x.c:761
#21 0x7f3809677e42 in _ecore_evas_idle_enter ../src/lib/ecore_evas/ecore_evas.c:295
#22 0x7f38098a89a4 in _ecore_call_task_cb ../src/lib/ecore/ecore_private.h:456
#23 0x7f38098a89a4 in _ecore_factorized_idle_process ../src/lib/ecore/ecore_idler.c:35
#24 0x7f3809b29081 in _event_callback_call ../src/lib/eo/eo_base_class.c:2114
#25 0x7f3809b29081 in _efl_object_event_callback_call ../src/lib/eo/eo_base_class.c:2186
#26 0x7f3809b22d22 in efl_event_callback_call ../src/lib/eo/eo_base_class.c:2189
#27 0x7f38098aae44 in _ecore_main_loop_iterate_internal ../src/lib/ecore/ecore_main.c:2466
#28 0x7f38098ab689 in _ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1231
#29 0x7f38098b05e0 in _efl_loop_begin ../src/lib/ecore/efl_loop.c:57
#30 0x7f38098af77c in efl_loop_begin src/lib/ecore/efl_loop.eo.c:28
#31 0x7f38098ab755 in ecore_main_loop_begin ../src/lib/ecore/ecore_main.c:1316
#32 0x7f380d14ba1f in elm_run ../src/lib/elementary/elm_main.c:1359
#33 0x557d07b2d298 in main ../src/examples/Texmap.cpp:176
#34 0x7f380b533c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#35 0x557d07b2d3c9 in _start (/home/junsu/dev/os/thorvg/build/src/examples/Texmap+0xb3c9)
warning message
[35/42] Compiling C++ object src/libthorvg-0.dll.p/lib_sw_engine_tvgSwRaster.cpp.obj
In file included from ../src/lib/sw_engine/tvgSwRasterTexmap.h:96,
from ../src/lib/sw_engine/tvgSwRaster.cpp:83:
../src/lib/sw_engine/tvgSwRasterTexmapInternal.h: In function 'void _rasterPolygonImageSegment(SwSurface*, const SwImage*, const SwBBox*, int, int, uint32_t (*)(uint32_t), AASpans*)':
../src/lib/sw_engine/tvgSwRasterTexmapInternal.h:76:9: warning: 'maxx' may be used uninitialized [-Wmaybe-uninitialized]
76 | if (x2 > maxx) x2 = maxx;
| ^~
../src/lib/sw_engine/tvgSwRasterTexmapInternal.h:33:19: note: 'maxx' was declared here
33 | int32_t minx, maxx;
| ^~~~
../src/lib/sw_engine/tvgSwRasterTexmapInternal.h:75:9: warning: 'minx' may be used uninitialized [-Wmaybe-uninitialized]
75 | if (x1 < minx) x1 = minx;
| ^~
../src/lib/sw_engine/tvgSwRasterTexmapInternal.h:33:13: note: 'minx' was declared here
33 | int32_t minx, maxx;
| ^~~~
This would fail building with Visual Studio 2017, at least downstream in Godot
where we undefine old Windows compilers' non-standard `min`/`max` macros (see
`minmax.h`/`NOMINMAX`).
Some gcc versions and configurations was giving an error:
error: "comparison of integer expressions of different signedness: 'const SwCoord'
{aka 'const long int'} and 'uint32_t' {aka 'unsigned int'} [-Werror=sign-compare]"
This patch should fix the error
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
Handle correctly duplicated spans from the multiple y span data.
Previous logic only expected the one single y span data from the rle.
However rle might have multiple y span data if the anti-aliasing is applied.
This patch also removed the bad design of the common engine
which handles the anti-alising option to ignore the anti-aliasing rle generation.
Just realized, it's difficult to control that condition due to scene-composition.
strokeOutline returned strokeExportOutline() is the address of mpool->strokeOutline[idx].
Assuming this value is null, mpoolRetStrokeOutline on line 617 will access mpool->strokeOutline[idx].
Logically, the logic of the mpool* functions does not occur in this case.
replace the transformed rle rgba image with the texmap raster.
this patch removes the several scattered transformed image rasterizer,
reuse the unified one texmap method instead.
yay, it's much clean and optimal.
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.
