On Thursday, 5 Apr 2001, Georg Acher wrote:
> I just looked into bumpmap.c and tried to figure out if it can profit from
> blocking and played a bit with the code. It seems that there is some major
> (performance) problem with the gimp_pixel_rgn_get/set_row-calls in Gimp
> 1.2.1.
>
> The original bumpmap took for my 1400*1400 image about 30s, when I commented
> out one of the gimp_pixel_rgn_get/set_row() that access the source or the
> destination image, the whole stuff took only about 2.4s, while the
> calculations were still done!
>
> I experimented a bit, and found out, that apparently the "switch" between
> get and set seems to be the problem. I changed the code to get 32 rows,
> calculate them and the write the 32 back. It took only 3s overall, the
> resulting image is the same as with the 30s boiling time.
Have a look at the gimp_pixel_rgns_register() and
gimp_pixel_rgns_process() functions. They do similar blocking on a
per-tile basis.
Most plugins should be using them, but ones with more complex access
patterns (eg accessing pixels across tile boundaries) probably won't.'
Typical use is something like this:
gimp_drawable_mask_bounds (drawable->id, &x1, &y1, &x2, &y2);
for (y = y1; y < y2; y += tile_width - (y % tile_width))
{
for (x = x1; x < x2; x += tile_width - (x % tile_width))
{
/* process the image in tile-sized regions */
for (pr = gimp_pixel_rgns_register (2, &src_rgn, &dest_rgn);
pr != NULL;
pr = gimp_pixel_rgns_process (pr))
{
src_row = src_rgn.data;
dest_row = dest_rgn.data;
for (row = 0; row < src_rgn.h; row++)
{
src = src_row;
dest = dest_row;
for (col = 0; col < src_rgn.w; col++)
{
/* do stuff with src[0..bpp] and dest[0..bpp] */
src += src_rgn.bpp;
dest += dest_rgn.bpp;
}
src_row += src_rgn.rowstride;
dest_row += dest_rgn.rowstride;
}
}
}
}
Of course this precise form will only work where there's a one-to-one
correspondence between input and output pixels. I suspect whirl-pinch
has more complex access patterns, in which case you'll need to be more
creative with the loop structure.
Austin
