gimp/app/base/pixel-region.c

576 lines
14 KiB
C
Raw Normal View History

/* GIMP - The GNU Image Manipulation Program
1997-11-25 06:05:25 +08:00
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* This program is free software: you can redistribute it and/or modify
1997-11-25 06:05:25 +08:00
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
1997-11-25 06:05:25 +08:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
1997-11-25 06:05:25 +08:00
*/
#include "config.h"
1997-11-25 06:05:25 +08:00
#include <stdarg.h>
#include <string.h>
removed from CVS, they are generated. 2001-12-07 Sven Neumann <sven@gimp.org> * app/core/gimpmarshal.[ch]: removed from CVS, they are generated. * app/base/Makefile.am * app/base/base-enums.h: new file defining enums that are to be registered. Used to build app/base/base-enums.c. * app/base/base-types.h: include base-enums.h. * tools/pdbgen/Makefile.am * tools/pdbgen/enumcode.pl * tools/pdbgen/enums.pl: parse the new base-enums.h file and modified the perl voodoo so it doesn't prefix enums with GIMP_ that are already properly namespaced. * app/core/core-types.h: don't need to chop GIMP from enum. * app/pdb/color_cmds.c * app/pdb/tools_cmds.c * libgimp/gimpenums.h * plug-ins/script-fu/script-fu-constants.c: regenerated. * app/config/gimpconfig-deserialize.[ch] * app/config/gimpconfig-serialize.[ch] * app/config/gimpconfig.[ch]: made GimpConfig an interface including a reasonable default implementation that works on object properties. * app/config/Makefile.am * app/config/gimpbaseconfig.[ch]: new GimpBaseConfig using the GimpConfig interface. Yet only used for testing from app/main.c. * app/main.c: test the new GimpBaseConfig object. * app/gimprc.c * app/base/base-config.h * app/base/*.c * app/core/gimpdatafiles.c * app/core/gimpdrawable-transform.c * app/core/gimppreviewcache.c * app/gui/preferences-dialog.c * app/paint-funcs/paint-funcs.c * app/xcf/xcf-seek.c: need to include glib-object.h since base-config contains registered enums now. Follow name change of InterpolationType to GimpInterpolationType.
2001-12-08 00:10:53 +08:00
#include <glib-object.h>
new directory app/base/ 2001-05-15 Michael Natterer <mitch@gimp.org> * configure.in: new directory app/base/ * app/Makefile.am * app/boundary.[ch] * app/brush_scale.[ch] * app/gimpchecks.h * app/gimplut.[ch] * app/pixel_processor.[ch] * app/pixel_region.[ch] * app/pixel_surround.[ch] * app/temp_buf.[ch] * app/tile.[ch] * app/tile_cache.[ch] * app/tile_manager.[ch] * app/tile_manager_pvt.h * app/tile_pvt.h * app/tile_swap.[ch]: moved to base/ * app/base/Makefile.am * app/base/base-types.h * app/base/*: new directory for the sub-object pixel maniplation and storage stuff. Does not include Gtk+ or anything outside base/. Did some cleanup in all files. * app/appenums.h * app/apptypes.h * app/core/gimpimage.h: removed types which are now in base/base-types.h. * app/base/base-config.[ch] * app/gimprc.[ch]: put the config variables for base/ to their own file so base/ doesn not have to include gimprc.h (does not yet work, i.e. the variables are un-configurable right now) * app/main.c: set a log handler for "Gimp-Base". * app/paint-funcs/Makefile.am * app/paint-funcs/paint-funcs.[ch]: removed the color hash which maps RGB to color indices because it's a totally standalone system which has nothing to do with the paint-funcs and introduced a GimpImage dependency. paint-funcs/ should be considered on the same sub-object (glib-only) level as base/, only in a different directory. * app/core/Makefile.am * app/core/gimpimage-colorhash.[ch]: put the color hash here. * app/gimage.c: don't invalidate the color hash here... * app/core/gimpimage.c: ... but in the colormap_changed() default inplementation. Initialize the hash in class_init(). * tools/pdbgen/Makefile.am: scan app/base/base-types.h for enums. * tools/pdbgen/enums.pl: regenerated. * app/[lots] * app/core/[of] * app/gui/[files] * app/pdb/[all] * app/tools/[over] * app/widgets/[the] * tools/pdbgen/pdb/[place]: changed #includes accordingly. And use base_config->value instead of the stuff from gimprc.h.
2001-05-15 19:25:25 +08:00
#include "base-types.h"
new directory app/base/ 2001-05-15 Michael Natterer <mitch@gimp.org> * configure.in: new directory app/base/ * app/Makefile.am * app/boundary.[ch] * app/brush_scale.[ch] * app/gimpchecks.h * app/gimplut.[ch] * app/pixel_processor.[ch] * app/pixel_region.[ch] * app/pixel_surround.[ch] * app/temp_buf.[ch] * app/tile.[ch] * app/tile_cache.[ch] * app/tile_manager.[ch] * app/tile_manager_pvt.h * app/tile_pvt.h * app/tile_swap.[ch]: moved to base/ * app/base/Makefile.am * app/base/base-types.h * app/base/*: new directory for the sub-object pixel maniplation and storage stuff. Does not include Gtk+ or anything outside base/. Did some cleanup in all files. * app/appenums.h * app/apptypes.h * app/core/gimpimage.h: removed types which are now in base/base-types.h. * app/base/base-config.[ch] * app/gimprc.[ch]: put the config variables for base/ to their own file so base/ doesn not have to include gimprc.h (does not yet work, i.e. the variables are un-configurable right now) * app/main.c: set a log handler for "Gimp-Base". * app/paint-funcs/Makefile.am * app/paint-funcs/paint-funcs.[ch]: removed the color hash which maps RGB to color indices because it's a totally standalone system which has nothing to do with the paint-funcs and introduced a GimpImage dependency. paint-funcs/ should be considered on the same sub-object (glib-only) level as base/, only in a different directory. * app/core/Makefile.am * app/core/gimpimage-colorhash.[ch]: put the color hash here. * app/gimage.c: don't invalidate the color hash here... * app/core/gimpimage.c: ... but in the colormap_changed() default inplementation. Initialize the hash in class_init(). * tools/pdbgen/Makefile.am: scan app/base/base-types.h for enums. * tools/pdbgen/enums.pl: regenerated. * app/[lots] * app/core/[of] * app/gui/[files] * app/pdb/[all] * app/tools/[over] * app/widgets/[the] * tools/pdbgen/pdb/[place]: changed #includes accordingly. And use base_config->value instead of the stuff from gimprc.h.
2001-05-15 19:25:25 +08:00
#include "pixel-region.h"
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
#include "temp-buf.h"
new directory app/base/ 2001-05-15 Michael Natterer <mitch@gimp.org> * configure.in: new directory app/base/ * app/Makefile.am * app/boundary.[ch] * app/brush_scale.[ch] * app/gimpchecks.h * app/gimplut.[ch] * app/pixel_processor.[ch] * app/pixel_region.[ch] * app/pixel_surround.[ch] * app/temp_buf.[ch] * app/tile.[ch] * app/tile_cache.[ch] * app/tile_manager.[ch] * app/tile_manager_pvt.h * app/tile_pvt.h * app/tile_swap.[ch]: moved to base/ * app/base/Makefile.am * app/base/base-types.h * app/base/*: new directory for the sub-object pixel maniplation and storage stuff. Does not include Gtk+ or anything outside base/. Did some cleanup in all files. * app/appenums.h * app/apptypes.h * app/core/gimpimage.h: removed types which are now in base/base-types.h. * app/base/base-config.[ch] * app/gimprc.[ch]: put the config variables for base/ to their own file so base/ doesn not have to include gimprc.h (does not yet work, i.e. the variables are un-configurable right now) * app/main.c: set a log handler for "Gimp-Base". * app/paint-funcs/Makefile.am * app/paint-funcs/paint-funcs.[ch]: removed the color hash which maps RGB to color indices because it's a totally standalone system which has nothing to do with the paint-funcs and introduced a GimpImage dependency. paint-funcs/ should be considered on the same sub-object (glib-only) level as base/, only in a different directory. * app/core/Makefile.am * app/core/gimpimage-colorhash.[ch]: put the color hash here. * app/gimage.c: don't invalidate the color hash here... * app/core/gimpimage.c: ... but in the colormap_changed() default inplementation. Initialize the hash in class_init(). * tools/pdbgen/Makefile.am: scan app/base/base-types.h for enums. * tools/pdbgen/enums.pl: regenerated. * app/[lots] * app/core/[of] * app/gui/[files] * app/pdb/[all] * app/tools/[over] * app/widgets/[the] * tools/pdbgen/pdb/[place]: changed #includes accordingly. And use base_config->value instead of the stuff from gimprc.h.
2001-05-15 19:25:25 +08:00
#include "tile-manager.h"
app/Makefile.am app/channel_pvt.h app/drawable_pvt.h app/gdisplayF.h 2000-12-29 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/channel_pvt.h * app/drawable_pvt.h * app/gdisplayF.h * app/gimpdrawableP.h * app/gimpimageP.h * app/layer_pvt.h * app/toolsF.h: removed these files. * app/apptypes.h * tools/pdbgen/enums.pl: added tons of opaque typedefs and enums. * tools/pdbgen/pdb/brush_select.pdb * tools/pdbgen/pdb/brushes.pdb * tools/pdbgen/pdb/channel.pdb * tools/pdbgen/pdb/color.pdb * tools/pdbgen/pdb/convert.pdb * tools/pdbgen/pdb/display.pdb * tools/pdbgen/pdb/drawable.pdb * tools/pdbgen/pdb/fileops.pdb * tools/pdbgen/pdb/gradient_select.pdb * tools/pdbgen/pdb/gradients.pdb * tools/pdbgen/pdb/help.pdb * tools/pdbgen/pdb/image.pdb * tools/pdbgen/pdb/layer.pdb * tools/pdbgen/pdb/pattern_select.pdb * tools/pdbgen/pdb/patterns.pdb * tools/pdbgen/pdb/selection.pdb * tools/pdbgen/pdb/tools.pdb * app/*: chainsaw #include cleanup: - Never (never!!) include stuff in header files except where we need access to structures' contents (like derived objects). - Added prototypes and proper formating in many files. - The #include order in *all* *.c files is as follows: #include "config.h" #include <system stuff> #include <gtk/gtk.h> #include "apptypes.h" #include "gimp stuff" #include "libgimp stuff" #include "libgimp/gimpintl.h" By following this scheme we can easily see a file's dependencies from it's #include's and can grep for the inclusion to find out where a file is used. * tools/pdbgen/app.pl: changed to follow the include scheme above. * libgimp/Makefile.am * libgimp/gimpuitypes.h: new file, included from libgimp/gimpui.h and from app/apptypes.h. * libgimp/gimpcolorbutton.[ch] * libgimp/gimpdialog.[ch] * libgimp/gimphelpui.[ch] * libgimp/gimpparasite.[ch] * libgimp/gimppatheditor.[ch] * libgimp/gimpprotocol.c * libgimp/gimpquerybox.[ch] * libgimp/gimpsizeentry.[ch] * libgimp/gimptypes.h * libgimp/gimpui.h * libgimp/gimpunit.h * libgimp/gimpunitmenu.[ch] * libgimp/gimpwidgets.[ch]: changed accordingly. * plug-ins/FractalExplorer/Dialogs.c * plug-ins/gdyntext/message_window.c * plug-ins/imagemap/imap_default_dialog.c * plug-ins/imagemap/imap_file.c: these files used to include "libgimp/gimpui.h" without including "libgimp/gimp.h". This is no longer possible because the libgimpui headers don't inlcude "libgimp/gimpunit.h" any more.
2000-12-29 23:22:01 +08:00
#include "tile.h"
1997-11-25 06:05:25 +08:00
1997-11-25 06:05:25 +08:00
/*********************/
/* Local Functions */
static gint get_portion_width (PixelRegionIterator *PRI);
static gint get_portion_height (PixelRegionIterator *PRI);
static PixelRegionIterator * pixel_regions_configure (PixelRegionIterator *PRI);
static void pixel_region_configure (PixelRegionHolder *PRH,
PixelRegionIterator *PRI);
1997-11-25 06:05:25 +08:00
/**************************/
/* Function definitions */
void
pixel_region_init (PixelRegion *PR,
TileManager *tiles,
gint x,
gint y,
gint w,
gint h,
gboolean dirty)
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PR->data = NULL;
PR->tiles = tiles;
PR->curtile = NULL;
PR->offx = 0;
PR->offy = 0;
PR->bytes = tile_manager_bpp (tiles);
PR->rowstride = PR->bytes * TILE_WIDTH;
PR->x = x;
PR->y = y;
PR->w = w;
PR->h = h;
PR->dirty = dirty;
PR->process_count = 0;
}
void
pixel_region_init_temp_buf (PixelRegion *PR,
TempBuf *temp_buf,
gint x,
gint y,
gint w,
gint h)
{
PR->data = temp_buf_get_data (temp_buf);
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PR->tiles = NULL;
PR->curtile = NULL;
PR->offx = 0;
PR->offy = 0;
PR->bytes = temp_buf->bytes;
PR->rowstride = temp_buf->width * temp_buf->bytes;
PR->x = x;
PR->y = y;
PR->w = w;
PR->h = h;
PR->dirty = FALSE;
PR->process_count = 0;
}
void
pixel_region_init_data (PixelRegion *PR,
guchar *data,
gint bytes,
gint rowstride,
gint x,
gint y,
gint w,
gint h)
{
PR->data = data;
PR->tiles = NULL;
PR->curtile = NULL;
PR->offx = 0;
PR->offy = 0;
PR->bytes = bytes;
PR->rowstride = rowstride;
PR->x = x;
PR->y = y;
PR->w = w;
PR->h = h;
PR->dirty = FALSE;
PR->process_count = 0;
1997-11-25 06:05:25 +08:00
}
void
pixel_region_resize (PixelRegion *PR,
gint x,
gint y,
gint w,
gint h)
1997-11-25 06:05:25 +08:00
{
PR->x = x;
PR->y = y;
PR->w = w;
PR->h = h;
}
void
pixel_region_get_row (PixelRegion *PR,
gint x,
gint y,
gint w,
guchar *data,
gint subsample)
1997-11-25 06:05:25 +08:00
{
Tile *tile;
guchar *tile_data;
gint inc;
gint end;
gint boundary;
gint b;
gint npixels;
gint bpp;
1997-11-25 06:05:25 +08:00
end = x + w;
bpp = PR->bytes;
inc = subsample * bpp;
if (subsample == 1)
{
if (PR->tiles)
read_pixel_data (PR->tiles, x, y, end - 1, y, data, PR->bytes);
else
memcpy (data, PR->data + x * bpp + y * PR->rowstride, w * bpp);
}
else
{
while (x < end)
{
tile = tile_manager_get_tile (PR->tiles, x, y, TRUE, FALSE);
tile_data = tile_data_pointer (tile, x, y);
npixels = tile_ewidth (tile) - (x % TILE_WIDTH);
if ((x + npixels) > end) /* make sure we don't write past the end */
npixels = end - x;
boundary = x + npixels;
for ( ; x < boundary; x += subsample)
{
for (b = 0; b < bpp; b++)
*data++ = tile_data[b];
tile_data += inc;
}
tile_release (tile, FALSE);
}
1997-11-25 06:05:25 +08:00
}
}
void
pixel_region_set_row (PixelRegion *PR,
gint x,
gint y,
gint w,
const guchar *data)
1997-11-25 06:05:25 +08:00
{
if (PR->tiles)
{
gint end = x + w;
1997-11-25 06:05:25 +08:00
write_pixel_data (PR->tiles, x, y, end - 1, y, data, PR->bytes);
}
else
{
memcpy (PR->data + x * PR->bytes + y * PR->rowstride, data, w * PR->bytes);
}
1997-11-25 06:05:25 +08:00
}
void
pixel_region_get_col (PixelRegion *PR,
gint x,
gint y,
gint h,
guchar *data,
gint subsample)
1997-11-25 06:05:25 +08:00
{
Tile *tile;
guchar *tile_data;
gint bpp;
gint inc;
gint end;
gint boundary;
gint b;
1997-11-25 06:05:25 +08:00
end = y + h;
bpp = PR->bytes;
1997-11-25 06:05:25 +08:00
while (y < end)
{
tile = tile_manager_get_tile (PR->tiles, x, y, TRUE, FALSE);
tile_data = tile_data_pointer (tile, x, y);
1998-08-12 01:35:34 +08:00
boundary = y + (tile_eheight(tile) - (y % TILE_HEIGHT));
if (boundary > end) /* make sure we don't write past the end */
boundary = end;
inc = subsample * bpp * tile_ewidth (tile);
1997-11-25 06:05:25 +08:00
for ( ; y < boundary; y += subsample)
{
for (b = 0; b < bpp; b++)
*data++ = tile_data[b];
tile_data += inc;
}
1997-11-25 06:05:25 +08:00
tile_release (tile, FALSE);
1997-11-25 06:05:25 +08:00
}
}
void
pixel_region_set_col (PixelRegion *PR,
gint x,
gint y,
gint h,
const guchar *data)
1997-11-25 06:05:25 +08:00
{
gint end = y + h;
gint bpp = PR->bytes;
1997-11-25 06:05:25 +08:00
write_pixel_data (PR->tiles, x, y, x, end-1, data, bpp);
1997-11-25 06:05:25 +08:00
}
gboolean
pixel_region_has_alpha (PixelRegion *PR)
{
if (PR->bytes == 2 || PR->bytes == 4)
return TRUE;
else
return FALSE;
}
PixelRegionIterator *
pixel_regions_register (gint num_regions,
...)
1997-11-25 06:05:25 +08:00
{
PixelRegionIterator *PRI;
gboolean found;
va_list ap;
1997-11-25 06:05:25 +08:00
if (num_regions < 1)
return NULL;
1997-11-25 06:05:25 +08:00
PRI = g_slice_new0 (PixelRegionIterator);
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PRI->dirty_tiles = 1;
1997-11-25 06:05:25 +08:00
va_start (ap, num_regions);
found = FALSE;
1997-11-25 06:05:25 +08:00
while (num_regions --)
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PixelRegionHolder *PRH;
PixelRegion *PR;
1997-11-25 06:05:25 +08:00
PR = va_arg (ap, PixelRegion *);
PRH = g_slice_new0 (PixelRegionHolder);
1997-11-25 06:05:25 +08:00
PRH->PR = PR;
if (PR != NULL)
{
/* If there is a defined value for data, make sure tiles is NULL */
if (PR->data)
PR->tiles = NULL;
PRH->original_data = PR->data;
PRH->startx = PR->x;
PRH->starty = PR->y;
PRH->PR->process_count = 0;
if (! found)
{
found = TRUE;
PRI->region_width = PR->w;
PRI->region_height = PR->h;
}
}
1997-11-25 06:05:25 +08:00
/* Add the pixel region holder to the list */
PRI->pixel_regions = g_slist_prepend (PRI->pixel_regions, PRH);
1997-11-25 06:05:25 +08:00
}
va_end (ap);
return pixel_regions_configure (PRI);
}
PixelRegionIterator *
added app/display/ and app/plug-in/. Empty for now except for the types 2001-08-17 Michael Natterer <mitch@gimp.org> * configure.in: added app/display/ and app/plug-in/. Empty for now except for the types files. * app/Makefile.am * app/appenums.h * app/apptypes.h: removed. * app/display/Makefile.am * app/display/display-types.h * app/plug-in/Makefile.am * app/plug-in/plug-in-types.h * app/gui/Makefile.am * app/gui/gui-types.h * app/pdb/Makefile.am * app/pdb/pdb-types.h: new files for typedefs. * app/appenv.h: added MessageHandlerType and StackTraceMode here. * app/undo_types.h: moved undo struct typedefs here. * app/tools/tools-types.h * app/core/core-types.h: added some enums and Tattoo here (renamed to GimpTattoo). * app/gdisplay.h: temp_hack: #include "display/display-types.h" * app/gimphelp.c: s/gtk_idle_add/g_idle_add/ * app/gimprc.c: don't use "gimprc" in token handlers but the passed "val1p" and "val2p". * app/image_map.[ch]: cleanup in preparation of making a GObject out of it. * app/base/pixel-region.[ch]: no need to pass the PixelRegionIterator around as void pointer. * app/core/gimp.[ch] * app/core/gimpcontext.[ch] * app/core/gimptoolinfo.[ch] * app/tools/tool_manager.c * app/widgets/gimpdnd.c: added the standard_tool_info to the Gimp object. * app/batch.c * app/file-open.c * app/file-save.c * app/file-utils.c * app/interface.c * app/main.c * app/path.[ch] * app/pathP.h * app/plug_in.h * app/core/gimpdrawable.[ch] * app/core/gimpimage-mask.c * app/core/gimpimage.[ch] * app/core/gimplayer.c * app/gui/color-area.c * app/gui/color-notebook.c * app/gui/colormap-dialog.c * app/gui/dialogs-commands.c * app/gui/dialogs-constructors.c * app/gui/error-console-dialog.c * app/gui/gradient-editor.c * app/gui/gradient-select.c * app/gui/indicator-area.c * app/gui/info-dialog.c * app/gui/palette-editor.c * app/gui/palette-select.c * app/gui/pattern-select.c * app/gui/session.c * app/gui/splash.c * app/gui/view-commands.c * app/tools/gimpinktool-blob.c * app/widgets/gimpcolorpanel.c * app/widgets/gimpdockbook.c * app/widgets/gimppreview.c * app/xcf/xcf-load.c * app/xcf/xcf-save.c * app/xcf/xcf.c: changed accordingly: s/Tattoo/GimpTattoo/, include the new types files, include <glib-object.h> instead of >gtk/gtk.h>. Bad hacks to get rid of SELECTION_OFF and friends in core/ (will be replaced ba a signal soon). * tools/pdbgen/Makefile.am: changed list of headers scanned for enums accordingly. * app/pdb/procedural_db.c * tools/pdbgen/app.pl * tools/pdbgen/pdb/channel.pdb * tools/pdbgen/pdb/display.pdb * tools/pdbgen/pdb/gradient_select.pdb * tools/pdbgen/pdb/image.pdb * tools/pdbgen/pdb/layer.pdb * tools/pdbgen/pdb/pattern_select.pdb: same fixes as above, added hacks to ensure that all foo-types.h files are included before all other gimp internal includes, include "pdb-types.h" unconditionally. * tools/pdbgen/enums.pl * app/pdb/*_cmds.c: regenerated.
2001-08-17 22:27:31 +08:00
pixel_regions_process (PixelRegionIterator *PRI)
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
GSList *list;
1997-11-25 06:05:25 +08:00
PRI->process_count++;
/* Unref all referenced tiles and increment the offsets */
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PixelRegionHolder *PRH = list->data;
1997-11-25 06:05:25 +08:00
if ((PRH->PR != NULL) && (PRH->PR->process_count != PRI->process_count))
{
/* This eliminates the possibility of incrementing the
* same region twice
*/
PRH->PR->process_count++;
/* Unref the last referenced tile if the underlying region
is a tile manager */
if (PRH->PR->tiles)
{
/* only set the dirty flag if PRH->dirty_tiles == TRUE */
tile_release (PRH->PR->curtile,
PRH->PR->dirty && PRI->dirty_tiles);
PRH->PR->curtile = NULL;
}
PRH->PR->x += PRI->portion_width;
if ((PRH->PR->x - PRH->startx) >= PRI->region_width)
{
PRH->PR->x = PRH->startx;
PRH->PR->y += PRI->portion_height;
}
}
1997-11-25 06:05:25 +08:00
}
return pixel_regions_configure (PRI);
}
void
added app/display/ and app/plug-in/. Empty for now except for the types 2001-08-17 Michael Natterer <mitch@gimp.org> * configure.in: added app/display/ and app/plug-in/. Empty for now except for the types files. * app/Makefile.am * app/appenums.h * app/apptypes.h: removed. * app/display/Makefile.am * app/display/display-types.h * app/plug-in/Makefile.am * app/plug-in/plug-in-types.h * app/gui/Makefile.am * app/gui/gui-types.h * app/pdb/Makefile.am * app/pdb/pdb-types.h: new files for typedefs. * app/appenv.h: added MessageHandlerType and StackTraceMode here. * app/undo_types.h: moved undo struct typedefs here. * app/tools/tools-types.h * app/core/core-types.h: added some enums and Tattoo here (renamed to GimpTattoo). * app/gdisplay.h: temp_hack: #include "display/display-types.h" * app/gimphelp.c: s/gtk_idle_add/g_idle_add/ * app/gimprc.c: don't use "gimprc" in token handlers but the passed "val1p" and "val2p". * app/image_map.[ch]: cleanup in preparation of making a GObject out of it. * app/base/pixel-region.[ch]: no need to pass the PixelRegionIterator around as void pointer. * app/core/gimp.[ch] * app/core/gimpcontext.[ch] * app/core/gimptoolinfo.[ch] * app/tools/tool_manager.c * app/widgets/gimpdnd.c: added the standard_tool_info to the Gimp object. * app/batch.c * app/file-open.c * app/file-save.c * app/file-utils.c * app/interface.c * app/main.c * app/path.[ch] * app/pathP.h * app/plug_in.h * app/core/gimpdrawable.[ch] * app/core/gimpimage-mask.c * app/core/gimpimage.[ch] * app/core/gimplayer.c * app/gui/color-area.c * app/gui/color-notebook.c * app/gui/colormap-dialog.c * app/gui/dialogs-commands.c * app/gui/dialogs-constructors.c * app/gui/error-console-dialog.c * app/gui/gradient-editor.c * app/gui/gradient-select.c * app/gui/indicator-area.c * app/gui/info-dialog.c * app/gui/palette-editor.c * app/gui/palette-select.c * app/gui/pattern-select.c * app/gui/session.c * app/gui/splash.c * app/gui/view-commands.c * app/tools/gimpinktool-blob.c * app/widgets/gimpcolorpanel.c * app/widgets/gimpdockbook.c * app/widgets/gimppreview.c * app/xcf/xcf-load.c * app/xcf/xcf-save.c * app/xcf/xcf.c: changed accordingly: s/Tattoo/GimpTattoo/, include the new types files, include <glib-object.h> instead of >gtk/gtk.h>. Bad hacks to get rid of SELECTION_OFF and friends in core/ (will be replaced ba a signal soon). * tools/pdbgen/Makefile.am: changed list of headers scanned for enums accordingly. * app/pdb/procedural_db.c * tools/pdbgen/app.pl * tools/pdbgen/pdb/channel.pdb * tools/pdbgen/pdb/display.pdb * tools/pdbgen/pdb/gradient_select.pdb * tools/pdbgen/pdb/image.pdb * tools/pdbgen/pdb/layer.pdb * tools/pdbgen/pdb/pattern_select.pdb: same fixes as above, added hacks to ensure that all foo-types.h files are included before all other gimp internal includes, include "pdb-types.h" unconditionally. * tools/pdbgen/enums.pl * app/pdb/*_cmds.c: regenerated.
2001-08-17 22:27:31 +08:00
pixel_regions_process_stop (PixelRegionIterator *PRI)
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
GSList *list;
1997-11-25 06:05:25 +08:00
PRI->process_count++;
/* Unref all referenced tiles and increment the offsets */
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PixelRegionHolder *PRH = list->data;
1997-11-25 06:05:25 +08:00
if ((PRH->PR != NULL) && (PRH->PR->process_count != PRI->process_count))
{
/* This eliminates the possibility of incrementing the
* same region twice
*/
PRH->PR->process_count++;
/* Unref the last referenced tile if the underlying region
is a tile manager */
if (PRH->PR->tiles)
{
tile_release (PRH->PR->curtile, PRH->PR->dirty);
PRH->PR->curtile = NULL;
}
}
1997-11-25 06:05:25 +08:00
}
if (PRI->pixel_regions)
{
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
g_slice_free (PixelRegionHolder, list->data);
g_slist_free (PRI->pixel_regions);
g_slice_free (PixelRegionIterator, PRI);
1997-11-25 06:05:25 +08:00
}
}
/*********************************/
/* Static Function Definitions */
static gint
1999-07-20 03:46:05 +08:00
get_portion_height (PixelRegionIterator *PRI)
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
GSList *list;
gint min_height = G_MAXINT;
gint height;
1997-11-25 06:05:25 +08:00
/* Find the minimum height to the next vertical tile
* (in the case of a tile manager) or to the end of the
* pixel region (in the case of no tile manager)
1997-11-25 06:05:25 +08:00
*/
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PixelRegionHolder *PRH = list->data;
1997-11-25 06:05:25 +08:00
if (PRH->PR)
{
/* Check if we're past the point of no return */
if ((PRH->PR->y - PRH->starty) >= PRI->region_height)
return 0;
if (PRH->PR->tiles)
{
height = TILE_HEIGHT - (PRH->PR->y % TILE_HEIGHT);
height = CLAMP (height,
0,
(PRI->region_height - (PRH->PR->y - PRH->starty)));
}
else
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
{
height = (PRI->region_height - (PRH->PR->y - PRH->starty));
}
1997-11-25 06:05:25 +08:00
if (height < min_height)
min_height = height;
}
1997-11-25 06:05:25 +08:00
}
return min_height;
}
static gint
1999-07-20 03:46:05 +08:00
get_portion_width (PixelRegionIterator *PRI)
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
GSList *list;
gint min_width = G_MAXINT;
gint width;
1997-11-25 06:05:25 +08:00
/* Find the minimum width to the next vertical tile
* (in the case of a tile manager) or to the end of
* the pixel region (in the case of no tile manager)
1997-11-25 06:05:25 +08:00
*/
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PixelRegionHolder *PRH = list->data;
1997-11-25 06:05:25 +08:00
if (PRH->PR)
{
/* Check if we're past the point of no return */
if ((PRH->PR->x - PRH->startx) >= PRI->region_width)
return 0;
if (PRH->PR->tiles)
{
width = TILE_WIDTH - (PRH->PR->x % TILE_WIDTH);
width = CLAMP (width,
0,
(PRI->region_width - (PRH->PR->x - PRH->startx)));
}
else
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
{
width = (PRI->region_width - (PRH->PR->x - PRH->startx));
}
1997-11-25 06:05:25 +08:00
if (width < min_width)
min_width = width;
}
1997-11-25 06:05:25 +08:00
}
return min_width;
}
static PixelRegionIterator *
1999-07-20 03:46:05 +08:00
pixel_regions_configure (PixelRegionIterator *PRI)
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
GSList *list;
1997-11-25 06:05:25 +08:00
/* Determine the portion width and height */
PRI->portion_width = get_portion_width (PRI);
1997-11-25 06:05:25 +08:00
PRI->portion_height = get_portion_height (PRI);
if (PRI->portion_width == 0 || PRI->portion_height == 0)
1997-11-25 06:05:25 +08:00
{
/* free the pixel regions list */
if (PRI->pixel_regions)
{
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
g_slice_free (PixelRegionHolder, list->data);
g_slist_free (PRI->pixel_regions);
g_slice_free (PixelRegionIterator, PRI);
}
1997-11-25 06:05:25 +08:00
return NULL;
}
PRI->process_count++;
for (list = PRI->pixel_regions; list; list = g_slist_next (list))
1997-11-25 06:05:25 +08:00
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PixelRegionHolder *PRH = list->data;
1997-11-25 06:05:25 +08:00
if ((PRH->PR != NULL) && (PRH->PR->process_count != PRI->process_count))
{
PRH->PR->process_count++;
pixel_region_configure (PRH, PRI);
}
1997-11-25 06:05:25 +08:00
}
return PRI;
}
static void
pixel_region_configure (PixelRegionHolder *PRH,
PixelRegionIterator *PRI)
1997-11-25 06:05:25 +08:00
{
/* Configure the rowstride and data pointer for the pixel region
* based on the current offsets into the region and whether the
* region is represented by a tile manager or not
*/
if (PRH->PR->tiles)
{
PRH->PR->curtile = tile_manager_get_tile (PRH->PR->tiles,
PRH->PR->x,
PRH->PR->y,
TRUE,
PRH->PR->dirty);
1997-11-25 06:05:25 +08:00
PRH->PR->offx = PRH->PR->x % TILE_WIDTH;
PRH->PR->offy = PRH->PR->y % TILE_HEIGHT;
1997-11-25 06:05:25 +08:00
PRH->PR->rowstride = tile_ewidth (PRH->PR->curtile) * PRH->PR->bytes;
PRH->PR->data = tile_data_pointer (PRH->PR->curtile,
PRH->PR->offx,
PRH->PR->offy);
1997-11-25 06:05:25 +08:00
}
else
{
some general cleanup. 2005-09-03 Michael Natterer <mitch@gimp.org> * app/base/pixel-region.[ch]: some general cleanup. (pixel_region_init_temp_buf) (pixel_region_init_data): new functions which initialize pixel regions on TempBufs and on raw contiguous arrays of pixel data. (pixel_region_configure): fixed a bug that has probably been there forever: when processing contiguous (non-tiled) data, interpret the original x and y coordinates of the region as offsets into the data. Before this fix, the initial x and y were simply ignored (by using them in a broken way), thus always forcing the upper left corner of the region being the beginning of the passed data. Lots of code was working around this problem by setting the pixel_region's data pointer to the proper starting pixel of the region in the middle the buffer. * libgimp/gimppixelrgn.c: some general cleanup. (gimp_pixel_rgn_configure): same fix as above. Fortunately, nobody seems to know that libgimp pixel regions can be used on arrays of data, just as core ones. Only two plug-ins were using this feature, and they are antique and written by spencer and federico, respectively. They both don't use offsets into the buffers and are not affected by this change. It's highly unlikely that anybody out there knows/uses this feature, so it can IMHO be safely changed. * app/base/temp-buf.c * app/core/gimpbuffer.c * app/core/gimpdrawable-combine.c * app/core/gimpdrawable-preview.c * app/core/gimpimage-preview.c * app/core/gimplayer.c * app/paint/gimpbrushcore.c * app/paint/gimpclone.c * app/paint/gimpconvolve.c * app/paint/gimpdodgeburn.c * app/paint/gimppaintcore.c * app/paint/gimpsmudge.c * app/tools/gimpiscissorstool.c * app/tools/gimppainttool.c: use the pixel_region_init_foo() functions instead of initializing regions of TempBufs and raw data manually. Removed lots of workarounds for the broken offset handling. The changed places of code are much more readable now.
2005-09-04 01:16:58 +08:00
PRH->PR->data = (PRH->original_data +
PRH->PR->y * PRH->PR->rowstride +
PRH->PR->x * PRH->PR->bytes);
1997-11-25 06:05:25 +08:00
}
PRH->PR->w = PRI->portion_width;
PRH->PR->h = PRI->portion_height;
}