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. Greetings, Ernst