He-he :) Right at the moment i was planning swapping and compression architecture =).<br><br>Well, i have several points:<br>1) If we change the format, then the first thing we should do is add VERSION field to the beginning of the file. Just to make our lives easier.<br>
<br>2) I was considering swapping, and i wanted to use LZO compression algorithm for this. According to some papers it is the fastest. (But those papers didn't cover LZF). [0]<br><br>3) For swapping it will surely be *not* efficient to work with a single tile. So i was going to join them into slabs and transport to disk at once, though compression will most likely be by-tile.<br>
<br>4) The thing that worries me the most is "compression sliding window". This term relates to most of LZx algorithms. LZO uses ~8-64KiB (do not know exactly). Regular tile has a size of 4*64*64=16KiB. It means that the tile can be fit into this window fully. This (not sure) means that the algorithm will work less efficient(!), than it can. <br>
<br>We must understand this effect fully before writing anything, or we can get many problems later.<br><br><br>More than that, effect you were exploring in March can (not sure, again) be a consequence of this. Original LZ77 algorithm does not depend on the size of input and almost linear in time (when the size of the input is much bigger than the size of the sliding window).<br>
<br><br>If that is so, this non-linearity can be a flaw of libLZF. Maybe, some post-processing with Haffman trees.<br><br>[0] - <a href="http://www.oberhumer.com/opensource/lzo/">http://www.oberhumer.com/opensource/lzo/</a><br>
<br><br>My conclusion:<br>1) I don't see any reason of writing tile-save-compression system separately and before the one that will be used in a swapper. We'll just make many code-duplications.<br><br>2) We can make kra-format more extensible before this. Yes. And if we define new format well I can easily fix KisTiledDataManager::write/read accordingly.<br>
<br><br><br><div class="gmail_quote">On Sun, Jun 13, 2010 at 4:36 PM, Cyrille Berger <span dir="ltr"><></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
TILESNUMBER 10<br>
COMPRESSIONSCHEME NONE<br>
DATA<br>
0,0,64,64<br>
</blockquote><div><br>^^^ What is in this line? Is there any difference with the data after ']'? And why there are additional digits appear when the compression is tured on?<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
[64x64xNxd binarydata]0,64,64,64<br></blockquote><div><br>^^^ What is 'Nxd'? pixels*depth?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
[64x64xNxd binarydata]0,64,128,64<br>
...<br>
[64x64xNxd binarydata]<br></blockquote><div><br><br>Actually, this is a good idea. I think for future use we need to allow different tilesize as well. So i would modify it like that:<br><br>VERSION 2<br>TILEWIDTH 64<br>
TILEHEIGHT 64<br>
PIXELSIZE 4<br>
TILESNUMBER 10<br>
COMPRESSIONSCHEME LZF<br>DATA<br>
0,0,64,64,12314<br>
[12314 bytes of binarydata]<br>64,64,64,64,3333<br>
[3333 bytes of binarydata]<br>
<br>I don't see a reason of saving width and height of every tile. Maybe, omit it? And make like:<br><br>VERSION 2<br>
TILEWIDTH 64<br>
TILEHEIGHT 64<br>
PIXELSIZE 4<br>
TILESNUMBER 10<br>
COMPRESSIONSCHEME LZF<br>
DATA<br>
0,0,12314<br>
[12314 bytes of binarydata]<br>
64,64,3333<br>
[3333 bytes of binarydata]<br><br><br>Pixel size will be used for asserts mostly.<br> <br></div></div><br clear="all"><br>-- <br>Dmitry Kazakov<br>