<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">
> So can we say for sure, that the buffer of some particular size will fit<br>
> the compressed tile, before actual compressing?<br>
</div>No we can't. Only data analysis can tell, all we can say is that we don't want<br>
the output buffer to be bigger than a certain size.<br>
<br>
For my problem, I don't care. For you, a solution might be to compress the<br>
data, check if there is enough space in your current chunk, if there is not,<br>
save the chunk and put the current tile in the next chunk.<br></blockquote><div><br>Then we should write a compression method into the file per every tile. The wrapper (KisTileCompressor) will check whether tile size became bigger after compression, and if it is so, will write uncompressed tile into the buffer.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It is a little digression of the real subject, but how are you going to write<br>
on the disk ? Using files, or mmap (like in the previous tile engine) ?<br></blockquote><div><br>I haven't decided yet, but i think, mmap+msync will work fine for this purpose. <br><br>Do you have some suggestions or warnings?<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">
> Well, KisTile takes col, row as arguments in the constructor, and, more<br>
> than that, reports about its creation to the memento manager. But the<br>
> problem is we don't know new tile's col,row before calling decompressor<br>
> (as it encapsulates the header) [3].<br>
</div>I would leave the header outside. The reason is that you won't gain much in<br>
compression by including it, and it will allow lazy loading/decompression of<br>
tiles.<br></blockquote><div><br>The header will be uncompressed, but it should be encapsulated into KisTileCompressor class, other way we will end up with numerous ugly switch/case clauses.<br> <br>Right to achieve this backward compatibility: KisTileCompressorV2_2, KisTileCompressorV2_3, ..., KisTileCompressorV2_9<br>
<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;">
<div class="im">
> Btw, we need return value to show how many bytes were read from the stream.<br>
</div>We kind of know the size of the output tile :)<br>
This is important, however for the compress function.<br></blockquote></div><br>If we completely hide decompression into compressor class, then we are not able to know how many bytes were read from the buffer and how far we should move the pointer for the next call to decompress().<br>
<br>to illustrate this:<br><br>char *buffer = buffer();<br><br>int bytesRead;<br>firstTile = decompress(buffer, &bytesRead);<br><br>buffer+=bytesRead;<br>secondTile = decompress(buffer, &bytesRead);<br><br><br>I think we've done much work to summarize and fix this on wiki =)<br>
<br>-- <br>Dmitry Kazakov<br>