Tiles data format
cberger at cberger.net
Wed Jun 16 14:05:16 CEST 2010
On Wednesday 16 June 2010, Dmitry Kazakov wrote:
> > > 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
> > 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?
Not sure if I see the point of msync (after all, you don't care about the data
once you unmap it). But otherwise it is ok.
> > 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().
More information about the kimageshop