<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;"><div class="im"><br>
> I think it means that if we make a global compression of the whole data<br>
> manager with lzf it will be the same 1.6s :)<br>
</div>And might be about the same compression rate. And is more complex and lose the<br>
possibility to read only certain tiles.<br></blockquote><div><br>ok.<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">
> Btw, are you going to disable KoStore compression only for data manager or<br>
> for entire document? I think the latter one is not really fun.<br>
</div>Only for data manager.<br></blockquote><div><br>ok too =)<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>
> libz allows it for sure. See deflateInit2() in [1]. *<br>
><br>
> *[1] - <a href="http://www.zlib.net/manual.html" target="_blank">http://www.zlib.net/manual.html</a><br>
<br>
</div>Yes, but all ZIP coder/decoder I have seen call deflateInit2 with -MAX_WBITS as<br>
window bits.<br></blockquote><div><br>Though it doesn't mean this is the best choice for compressing tiles =)<br>Ok, it can be quite difficult to modify KoStore for that.<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><div></div><div class="h5">
> Hm... wait! Your idea is even better in some way! We need only one<br>
> KisTileCompressor that uses different abstract compress engines. Yeah. You<br>
> are right with idea of KisAbstractCompressor. But it should provide a<br>
> couple of additional interfaces:<br>
><br>
> virtual qint32 estimateCompressedSize(qint32 sourceSize); // <- to be able<br>
> to compress tiles in one pass.<br>
> virtual void adjustForDataSize(qint32 tileDataSize); // <- this one will<br>
> configure sliding window size (and friends) for particular data-stream-size<br>
><br>
> What do you think?<br>
<br>
</div></div>I don't see the point of optimalBufferSize ? or estimateCompressedSize ? In our<br>
case the buffer should be the size of the tile, and the data is saved<br>
compressed only if the compression result is inferior to the size of the tile.<br>
I don't see the point in making it more complicated.<br></blockquote><div><br>Do these engines make compression in-place? If not we need to create buffer for this. This buffer should be smaller that the tile-size (now, i'm in doubt whether there is a guarantee for this from the LZ* for maximum size of compressed data, should take a look at [2] again). I'm going to have slabs of compressed tiles, those will be transferred to the disk at once, so i need to be able to check whether a slab can accept one more tile.<br>
<br>So can we say for sure, that the buffer of some particular size will fit the compressed tile, before actual compressing?<br><br>[2] - <a href="http://www.cs.duke.edu/courses/spring03/cps296.5/papers/ziv_lempel_1977_universal_algorithm.pdf">http://www.cs.duke.edu/courses/spring03/cps296.5/papers/ziv_lempel_1977_universal_algorithm.pdf</a><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;">
Also I don't know how the swapper will work, but for the loading of a file it<br>
is more convenient to have decompressTile(KisTileSP, quint8* buffer); (but then<br>
I would pass data pointer to have an interface that can be easilly used<br>
outside of the context :) )<br></blockquote></div><br>Well, KisTile takes col, row as arguments in the constructor, and, more than that, reports about its creation to the memento manager. But the problem is we don't know new tile's col,row before calling decompressor (as it encapsulates the header) [3].<br>
<br>So there are two possibilities:<br>Or we pass all the needed arguments for construction of a tile:<br>KisTileSP decompressTile(quint8* buffer, KisMementoManager* manager);<br><br>or we just pass KisTileHashTable as a factory of tiles that will create tiles with getTileLazy() - i think this is the best choice:<br>
quint32 decompressTile(quint8* buffer, KisTileHashTable* table);<br><br>Btw, we need return value to show how many bytes were read from the stream.<br><br><br><br>[3] - btw, we can have different KisTileCompressor for every version of kra ;)<br clear="all">
<br>-- <br>Dmitry Kazakov<br>