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.

Gimp-developer mailing list

Reply via email to