Tiles data format

Dmitry Kazakov dimula73 at gmail.com
Wed Jun 16 13:33:11 CEST 2010

> > So can we say for sure, that the buffer of some particular size will fit
> > the compressed tile, before actual compressing?
> No we can't. Only data analysis can tell, all we can say is that we don't
> want
> the output buffer to be bigger than a certain size.
> For my problem, I don't care. For you, a solution might be to compress the
> data, check if there is enough space in your current chunk, if there is
> not,
> save the chunk and put the current tile in the next chunk.

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.

> It is a little digression of the real subject, but how are you going to
> write
> on the disk ? Using files, or mmap (like in the previous tile engine) ?

I haven't decided yet, but i think, mmap+msync will work fine for this

Do you have some suggestions or warnings?

>  > 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].
> I would leave the header outside. The reason is that you won't gain much in
> compression by including it, and it will allow lazy loading/decompression
> of
> tiles.

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.

Right to achieve this backward compatibility: KisTileCompressorV2_2,
KisTileCompressorV2_3, ..., KisTileCompressorV2_9

 > Btw, we need return value to show how many bytes were read from the
> stream.
> We kind of know the size of the output tile :)
> This is important, however for the compress function.

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().

to illustrate this:

char *buffer = buffer();

int bytesRead;
firstTile = decompress(buffer, &bytesRead);

secondTile = decompress(buffer, &bytesRead);

I think we've done much work to summarize and fix this on wiki =)

Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100616/66fee765/attachment.htm 

More information about the kimageshop mailing list