Sven Neumann wrote:
> Have you looked at the code of the many plug-ins that use a preview
> already? The idea of a preview is to preview the effect. So you aren't
> going to manipulate the pixel regions at all. Instead you draw on the
> preview.
I'm looking at Dave Neary's sample code on the developer.gimp.org
website, which uses two pixel regions, calling gimp_pixel_rgn_get_row()
on one and gimp_pixel_rgn_set_row() on the other, and calls
gimp_drawable_preview_draw_region() to update the preview. If I use
gimp_pixel_rgns_process() to access the regions instead, the preview is
not updated with the new data.
> If you have specific question, it's probably best to make up a small
> test case and show us the code together with your question.
Replace the processing loops in Dave's blur() function:
for (ii = -bvals.radius; ii <= bvals.radius; ii++)
{
[...]
gimp_progress_update ((gdouble) i / (gdouble) height);
}
with:
guchar* pr = gimp_pixel_rgns_register(2, &rgn_in, &rgn_out);
for ( ; pr != 0; pr = gimp_pixel_rgns_process(pr)) {
guchar* src = rgn_in.data;
guchar* dst = rgn_out.data;
for (i = 0; i < rgn_in.h; ++i) {
guchar* s = src;
guchar* d = dst;
for (ii = 0; ii < rgn_in.w; ++ii) {
d[0] = 255 - s[0];
s += rgn_in.bpp;
d += rgn_out.bpp;
}
src += rgn_in.rowstride;
dst += rgn_out.rowstride;
}
}
--
David Hodson -- this night wounds time
_______________________________________________
Gimp-developer mailing list
[email protected]
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
