Both functions implemented using 128-bit registers.
avxRasterTranslucentRect is around 5 times faster than cRasterTranslucentRect (i7-8700 CPU - Coffe Lake)
picture must return the boundary info - 0, 0, w, h
We assume that it has a designated picture size.
Aside from this issue,
bounds() api must be reviewed, its behavior is quite in a trouble...
unless the result is not transformed, its information is useless...
@Issue: https://github.com/Samsung/thorvg/issues/741
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.
By choosing compress option, tvg tries to compress the data to reduce the binary size.
Since the compression has the double-edges sword, we provides an option to users
to select it by their demand. Basically, compression is better than non-compression.
After profiling, we decided to use the encoder/decoder of Guilherme R. Lampert's.
Here is the profiling result:
test.tvg: 296037 -> 243411 (-17%)
tiger.tvg: 54568 -> 50622 (-7%)
image-embedded.tvg: 2282 -> 1231 (-46%)
@Issue: https://github.com/Samsung/thorvg/issues/639
About compression method:
Lempel–Ziv–Welch (LZW) encoder/decoder by Guilherme R. Lampert
This is the compression scheme used by the GIF image format and the Unix 'compress' tool.
Main differences from this implementation is that End Of Input (EOI) and Clear Codes (CC)
are not stored in the output and the max code length in bits is 12, vs 16 in compress.
EOI is simply detected by the end of the data stream, while CC happens if the
dictionary gets filled. Data is written/read from bit streams, which handle
byte-alignment for us in a transparent way.
The decoder relies on the hardcoded data layout produced by the encoder, since
no additional reconstruction data is added to the output, so they must match.
The nice thing about LZW is that we can reconstruct the dictionary directly from
the stream of codes generated by the encoder, so this avoids storing additional
headers in the bit stream.
The output code length is variable. It starts with the minimum number of bits
required to store the base byte-sized dictionary and automatically increases
as the dictionary gets larger (it starts at 9-bits and grows to 10-bits when
code 512 is added, then 11-bits when 1024 is added, and so on). If the dictionary
is filled (4096 items for a 12-bits dictionary), the whole thing is cleared and
the process starts over. This is the main reason why the encoder and the decoder
must match perfectly, since the lengths of the codes will not be specified with
the data itself.
Calling picture->load after it was already once called resulted in
segmentation fault or memory leak (depending on whether the vector (svg, tvg)
or raster (jpg, png, raw) file was loaded).
This patch checks the image has already been loaded. If so, the load()
returns InsufficientCondition.
@issue: fixes#719
if the last contour dispatching is dealt with closed command but actual command
is not the closed, the close tag is written with the opened
In this case, stroking rendering is buggy.
This change protects against negative value in unsigned int of
RenderRegion.x/y. This fixes a problem of invisible paint if ClipPath
bounds was negative.
@issue: #704
This optimizes binary size by skipping the scene if it has the only child.
though the reduced size is too trivial size (avg 0.4% as far as I checked our example svgs),
we can reduce the loading job & runtime memory as well.
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.
tvg file stores the version info of thorvg when it's generated,
in order to compare it with the runtime thorvg version when it's loaded.
For this, thorvg builds up the current version of symbol on the initilaization step,
that can be referred by the tvg loader.
* 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.
Pixel-based image picture doesn't work at size() method.
Obvisouly, we missed to implement it properly.
This patch corrects it.
@Issue: https://github.com/Samsung/thorvg/issues/656
Changes:
- Added 'neon' vector option in build system
- Introduced neon version of rasterRGBA32 API, which improves
speed of the funciton on ARM cpu's around ~35%
if many canvas instances own private memory pool,
the memory usage can be increased linearly.
To prevent memory usage, flush out memory pool from the clear()
if the canvas uses private memory pool.
Bitmap based pictures doesn't need the viewbox,
LoaderModule should delegate the viewbox to the derived classes which
having vector-based image loaders such as svg, tvg.
In that case, paint resizing can be performed by the loaders by own
policy.
replace from Scene to Paint at the internal interface.
Picture doesn't need to know the returned Node type.
base class, Paint is enough to in the data passing.
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
tvg saver is a new module to export tvg files.
In this patch, it also contains the infrastructure of saver module
to expand other types of savers such as png, jpg, etc.
To save the tvg file from a paint, you can use the Saver feature, for example:
auto saver = tvg::Saver::gen();
saver->save(paint, "sample.tvg");
saver->sync();
Later, you can read the "sample.tvg" using Picture.
auto picture = tvg::Picture::gen();
picture->load("sample.tvg");
...
The behavior of the saver will work on sync/async based on the threading setting of the initializer.
Thus if you wish to have a benefit of it, you must call sync() after the save() in the proper delayed time.
Otherwise, you can call sync() immediately.
Note that, the asynchronous tasking is depent on the saver module implementation.
Also, you need to enable tvg saver/loader modules from meson option. (yet this feature is under the beta)
@API Addition:
Result Saver::save(std::unique_ptr<Paint> paint, const std::string& path) noexcept;
Result Saver::sync() noexcept;
@Examples: tvgSaver
@Co-author: Mira Grudzinska <m.grudzinska@samsung.com>
replace from ofstream to FILE
We know both have the same purpose, we always prefer the less binary size.
So... this brings the binary size reduction.
1918496 => 1913528
