Kelly Martin wrote:
> If the algorithm is pixel-by-pixel (each output pixel depends only on
> exactly one input pixel from each region being iterated over, and
> those regions are all the same size) there is absolutely no excuse not
> to use the pixel region iterator, which will automagically minimize
> tile accesses to the lowest number possible.
> IIRC, the bumpmap
> drawable need not be the same size as the input/output drawable,
The sizes may be different indeed and there also an option for tiling
(repeating) the bitmap.
> so a
> pure region iterator cannot be used, but at least using the region
> iterator for the input & output would limit the use of direct fetches
> to the bumpmap drawable.
When the output pixel depends on neighboring pixels (e.g. I strongly
suspect that bumpmap uses a 3 x 3 neighborhood) the region iterator does
not work very well.
Sometime ago I wrote a piece of code that can handle neighborhoods
without fetching tiles twice. I needed this because I was applying
convolutions where I needed a neighborhood of say 20x20. Basically what
my code does is maintain a buffer that holds two rows of tiles plus some
extra for the vertical neighborhood. It handles those nasty details like
adding borders and fetching tiles. It works for my plugin but it must
still be documented and some missing features must still be implemented.
There are several filters where it could potentially be used, so if
anyone is interested I could try to clean it up.
Gimp-developer mailing list