The net effect of making an image tiled, is that a grid is added
to the image, *without* obscuring part of the image with
grid lines: all pixel information is preserved. The lines
(aka borders) are added in-between the pixels of the image.
As a result, the image dimensions increase, and the image
may look slightly distorted. (a straight slanted line crossing
a tile border, will not look straight at the crossing).
Example:
Picture:
[ ]
[ H H III TTTTT H H EEEEE RRRR EEEEE ]
[ H H I T H H E R R E ]
[ HHHHH I T HHHHH EEE RRRR EEE ]
[ H H I T H H E R R E ]
[ H H III T H H EEEEE R R EEEEE ]
[ ]
Same picture with 10x5 tiles:
[ | | | | ]
[ H H II|I TTTT|T H H |EEEEE RRR|R EEEEE ]
[ H H I| T | H H |E R | R E ]
[ HHHHH I| T | HHHHH |EEE RRR|R EEE ]
[ H H I| T | H H |E R | R E ]
[----------|----------|----------|----------|----------]
[ H H II|I T | H H |EEEEE R | R EEEEE ]
[ | | | | ]
Added the option to bulk load and cache entire world rows at
a time when using sqlite. Caching is implemented in the
database class this time around.
Enabled using --sqlite-cacheworldrow on the command line.
This is essentially re-introduces the database access strategy
that was used originally, but as an option.
Currently, one block is read at a time from the database.
The original behavior was to read and cache one entire world
row at a time, irrespective of whether or not only a (small)
subsection of the world was being mapped.
Under some circumstances, in particular if the entire world is
mapped or a relatively large percentage of it (blocks-wise), the
bulk loading and caching may outperform the one-by-one strategy,
even though it usually loads many more blocks than are actually
needed.
It seems that leveldb won't benefit from any kind of caching or
bulk loading of blocks, so none was implemented.
Leveldb does compile now. Still not tested on a database :-(
Improved the database statistics (printed with --verbose).
