[Lots of people writing barking mad things about tile swapping]

Look, you're all missing the point.

Gimp does it's own tile swapping not because it wants to control the
layout on disk.  As some of you have pointed out, this is futile.

The only reason to swap a tile at a time is to do with controlling how
far apart in memory neighbouring pixels are.

Consider a very wide image.  If it is stored as a large linear array
in memory (possibly paged by the OS to an OS-managed swap file), then
the common operation of consulting a pixel above or below the current
one results in needing to skip a large number of bytes through the
linear array.  This results in poor CPU cache performance.  So, we use
a tiled memory layout.  Once the data is in a tiled representation in
memory, there seems little point in converting it into a linear buffer
before writing it to disk.  This would certainly take more time than
it would to just hand the data to the OS.

Now, the size of a tile cache (ie number of tiles we'd like to be able
to access as speedily as possible) should be a little over the number
of tiles it takes to cover the width of the image.  This is so that
filters which iterate over every single pixel from left to right, top
to bottom, perform better on the horizontal boundary between adjacent
strips of tiles.  Consider a 3x3 convolution (let's say a blur
matrix).  When the center of the matrix is at the top of the second
row of tiles, the top of the matrix needs to reference the first row
of tiles.  It is helpful for performance to have this top row
available.  Which means caching ceil(img_width / tile_width) + 1

And gentlemen, this is not rocket science.  It's what undergraduates
are normally taught in their basic "OS Functions" lectures.  The gimp
is a good example of why application-specific paging control can be a
performance boost.

Now can we drop this silly subject, please?


Reply via email to