This reverts commit cd5116b053.
Ah this breaks the Stress example due to Picture::duplicate() is not available...
Need to consider and come back again.
* common: added colorSpace() function
This patch introduces colorSpace() function for SW and GL engine.
* infra: change LoadModule:read() into LoadModule:read(uint32_t colorspace)
This patch changes LoadModule:read() into LoadModule:read(uint32_t colorspace)
* picture: implement passing colorspace into loader
This patch implements passing colorspace into loaders.
Loader->read is now called on the first update.
* external_jpg_loader: support colorspaces
* external_png_loader: support colorspaces
"runtime error: load of misaligned address 0x7fb67895c815 for type 'unsigned int', which requires 4 byte alignment"
This is actually not an issue but we can resolve it with an easy workaround,
since we don't need to see this report repeatedly.
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.
tvg binary format might break the compatibility if any major features have been changed.
It's allowed to do it when the major version is upgraded.
In that case, still we need to support the backward compatibility,
we can provide multiple binary interpreters and choose the proper one
based on the current loading tvg binary format version.
Thus, you can add further interpreters if it's necessary in the future.
Our policy is to derive the TvgBinInterpreterBase class to make it running on
the interface.
for example, if the major version is upgraded 1.x, you can implement TvgBinInterpreter1.
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.
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.
This patch introduces tvg loader module for loading .tvg binary files.
This allows to load and reuse pregenerated scene.
tvg file format:
.tvg is a binary file format designed for saving/restoring the scene content.
It allows to save scenes and reuse them in other apps or to restore state of
the application.
@Example:
auto picture = tvg::Picture::gen();
picture->load(EXAMPLE_DIR"/tvg_file.tvg");
canvas->push(move(picture));
@API Additions:
Result paint(std::unique_ptr<Paint> paint) noexcept;
@Issue: Issue ticket is #375.
