<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* .kra with compressed tiles (lzf) and no global compression: 67MB, saving<br>
time 1.6s<br></blockquote><div> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* .kra with uncompressed tiles and global compression: 28MB, saving time 28s<br>
* .kra with compressed tiles using deflate and no global compression: 27MB<br>
saving time 23s<br></blockquote><div>^^ both 'deflate'?<br><br>I think it means that if we make a global compression of the whole data manager with lzf it will be the same 1.6s :)<br><br>Btw, are you going to disable KoStore compression only for data manager or for entire document? I think the latter one is not really fun.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> Well, first, there is an abstract compressor should be done first, to will<br>
> allow swapper to save data in the same format as kra. And life of both of<br>
> us will be much easier =)<br>
</div>I don't think there is an obligation of using the same algorithm for both<br>
solution. The requirement for saving is the fastest is the best.<br></blockquote><div><br>Absolutely the same requirement for swapping =)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> And second, i'm not sure we interpreted the results of those tests right.<br>
> Sliding window size of zlib is configurable and it is big by default, so it<br>
> could cause the difference.<br>
><br>
> If we interpreted them wrong, then it's better to replace (configure)<br>
> compression of the KoStore, than to do this change.<br>
</div>Except there is no API to do that (and it uses KDE stuff, so no easy change<br>
here). And assuming the ZIP file format even allows that.<br></blockquote><div><br>libz allows it for sure. See deflateInit2() in [1].
<b><br><br></b>[1] - <a href="http://www.zlib.net/manual.html">http://www.zlib.net/manual.html</a> <br><br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> PS:<br>
> Anyway, if you wish, i can hurry with this abstract compressor a bit. =)<br>
<br>
</div>class AbstrstractCompress { virtual compress(void* data, int data_length,<br>
void* output, int output_length) = 0; virtual decompress(void* data, int<br>
data_length, void* output, int output_length) = 0; }; ? Or am I missing<br>
something ?<br>
<br>
or compress(void* data, int data_length, void* output, int output_length,<br>
CompressionMethod)<br>
<br>
Well anyway, the new format for tiles allows room for experimentation, so I<br>
will implement that, and then we can play with it.<br>
</blockquote></div><br>Something like that, but a bit more high-level. (do we need fast compression for the stuff other than tiles?) I want to encapsulate tile header into it. (the one that puts origin of the tile, it's size and etc). Something like:<br>
<br>class KisTileCompressor {<br> qint32 optimalBufferSize(); // for LZ77 - there is a formula for estimating high boundary for compressed size<br> void compressTile(KisTileSP tile, quint8* buffer);<br> KisTileSP decompressTile(quint8* buffer);<br>
};<br clear="all"><br>In such a case i will use the same binary file format for swapper, this will allow simply copy swapper's data to the kra file when saving.<br><br>Hm... wait! Your idea is even better in some way! We need only one KisTileCompressor that uses different abstract compress engines. Yeah. You are right with idea of KisAbstractCompressor. But it should provide a couple of additional interfaces:<br>
<br>virtual qint32 estimateCompressedSize(qint32 sourceSize); // <- to be able to compress tiles in one pass.<br>virtual void adjustForDataSize(qint32 tileDataSize); // <- this one will configure sliding window size (and friends) for particular data-stream-size<br>
<br>What do you think?<br><br>-- <br>Dmitry Kazakov<br>