GIMP">
gimp.h'>
gimpenums.h'>
OC">
]>
Writing a &gimp; Plug-InTurnerKevinacapnotic@users.sourceforge.net1998-2000Kevin Turner
&opl;
IntroductionThis document is based on my experiences of writing plug-ins
for the
GNU Image Manipulation Program
in C. Much of this document is likely relevant to &gimp;
plug-ins in other languages, but I'm too much of a monoglot to
know for sure. A basic working knowledge of C is assumed, but
extensive experience isn't necessary.The Source is Your Friend TooThis document contains frequent code snippits, but to get
any context, you'll probably want to be working through (reading
and/or writing) some plug-in code alongside it. Miles O'Neal has extensively
annotated his randomize plug-in, making it a good place
to start. You may want to look at several — each one will
have their own peculiar parts that they've done well or poorly
on.Status of this DocumentThis document was authored for version 1.0 of &gimp;. But
now &gimp; 1.1 is now frozen and on its glacial journey towards
the 1.2 release. There have been a few changes and a
considerable number of additions to libgimp which have yet to
been documented here. While that makes this somewhat out of
date at current, it is still reasonably accurate, and may serve
as an overview for getting started with your plug-in.
In addition, two valueable new resources have been
created. One is the libgimp reference documentation, which
documents all the functions in the current libgimp. It is
distributed in the devel-docs directory of the &gimp; distribution, and
is also available
on-line. The second is the &gimp; plug-in template,
which contains a skeleton of all the files you need to get
started on you own plug-in, including support for
autoconf, internationalization using
gettext, and &gimp;'s on-line help
system. It's available as the gimp-plugin-template module in the GNOME CVS
repository and is mirrored by &gimp; plug-ins
CVS.Styles in this DocumentDepending on your output medium's implementation of style
sheets, you may notice different parts of this document have
different styles.
printf("This code was quoted from the GIMP sources.");
/* This is a comment in the source code. */
printf("This is example code to illustrate a point.");
/* This is a comment in the source code. */
References to the &gimp; source code are linked to the
LXR engine at
cvs.gnome.org. Caution: That may be a newer version of
the source than is is use by the general public, but I couldn't
find anything else to link to. If you're developing for the
stable version of &gimp;, check your own copy of the source.
Also, line numbers may have changed since I established the
links … If you find that to be the case, please let me
know.Essentials of a Plug-inThere are some things every plug-in simply
must have if it is to be considered a
plug-in, no matter what its purpose. Mainly, the plug-in has to
register itself in the &gimp;'s procedure database, and it has to
have a function to run when &gimp; calls for that procedure. Here
we'll look at how these functions are called, and just what
components they really need.<symbol>MAIN</symbol>main()Every C program has a main() function
— the first function that is called when the program is
executed. The typical &gimp; plug-in's main function is, in its
entirety, as follows:MAIN()
MAIN is a macro, defined in libgimp/gimp.h, which calls a
gimp_main function, which in turn does all
sorts of neat stuff. It tries to make sure the plug-in is being
called by &gimp;, sets up some signal handling, sets up
communication between the plug-in and &gimp;, and queries the
plug-in if need be.&gimp; queries plug-ins on start-up, and it expects them
to register themselves in the procedural database (PDB). But
how does &gimp; know what function to call when it queries? It
checks the value of the global variable
PLUG_IN_INFO, of type
GimpPlugInInfo. From &gimph;:The GimpPlugInInfo Structure
typedef void (* GimpInitProc) (void);
typedef void (* GimpQuitProc) (void);
typedef void (* GimpQueryProc) (void);
typedef void (* GimpRunProc) (gchar *name,
gint nparams,
GimpParam *param,
gint *nreturn_vals,
GimpParam **return_vals);
struct _GimpPlugInInfo
{
/* called when the gimp application initially starts up */
GimpInitProc init_proc;
/* called when the gimp application exits */
GimpQuitProc quit_proc;
/* called by the gimp so that the plug-in can inform the
* gimp of what it does. (ie. installing a procedure database
* procedure).
*/
GimpQueryProc query_proc;
/* called to run a procedure the plug-in installed in the
* procedure database.
*/
GimpRunProc run_proc;
};
So PLUG_IN_INFO consists of pointers to
four functions. The first two are ran when &gimp; starts and
exits, not commonly used among the plug-ins, and so are usually
set to NULL. The third is the
query function, which many plug-in authors
have chosen to name query(). The fourth is
called when the plug-in's procedure is to be run, and is,
surprisingly enough, often called run().
An example:Defining PLUG_IN_INFO
/* Function prototypes */
static void query (void);
static void run (gchar *name,
gint nparams,
GimpParam *param,
gint *nreturn_vals,
GimpParam **return_vals);
/* Setting PLUG_IN_INFO */
GimpPlugInInfo PLUG_IN_INFO =
{
NULL, /* init_proc */
NULL, /* quit_proc */
query, /* query_proc */
run, /* run_proc */
};
The Query ProcedureAs mentioned, &gimp; expects plug-ins to register
themselves in the PDB when they're queried. This is done through
gimp_install_procedure (again, from
&gimph;):gimp_install_procedurevoid gimp_install_procedurechar* namechar* blurbchar* helpchar* authorchar* copyrightchar* menu_pathchar* image_typesGimpPDBProcType typeint nparamsint nreturn_valsGimpParamDef* paramsGimpParamDef* return_valsParameters name through
date should be fairly self-explanatory.
On the rest, I'll make some comment:
FIXMEcallout
The following list should be a callout list to the
programlisting above.menu_pathA string describing where in the menu the procedure
should be installed. It begins with one of
<Toolbox>, <Image>, <Load>, or
<Save>, followed by the menu path. For example, the
Maze plug-in's menu_path is <Image>/Filters/Render/Patterns/Maze....&gimp; uses this information not only to place the
menu, but also to decide what type of procedure it
is. This affects its decision on which parameters are
necessary for the procedure. Note also that a
menu_path isn't required if you
wish to install a procedure without one, but that's not
the case for most plug-ins.Source reference:
FIXMEsource ref
app/plug_in.c,
plug_in_handle_proc_installimage_typesA string listing what image types the plug-in will
accept; any of RGB, RGBA, RGB*, GRAY, GRAYA, GRAY*,
INDEXED, INDEXEDA, INDEXED*. RGB* is simply shorthand for
both RGB and RGBA (same applies for GRAY* and
INDEXED*). The list may be separated by spaces, tabs, or
commas. Example: RGB*, INDEXED means the
plug-in likes all RGB images (with or without alpha),
indexed-color images (only without alpha), but not
grayscale images of any sort.Source reference: app/plug_in.c,
FIXMEsource ref
plug_in_image_types_parsenparams, nreturn_valsThe number of parameters (or return values)
the procedure uses.nparams, nreturn_valsSee below.PDB Parameters*params points to an array of
parameter definitions. nparams is an
integer that tells the number of parameters (equal to the
length of the array). A parameter definition is of type
GimpParamDef, which has three parts &gimph;:
struct _GimpParamDef
{
GimpPDBArgType type;
gchar *name;
gchar *description;
};
Values for GimpPDBArgType are listed in &enumsh;. Setting
up parameters can be done like so:Establishing an array of parameters.
static GParamDef params[] =
{
{ GIMP_PDB_INT32, "run_mode", "Interactive, non-interactive" },
{ GIMP_PDB_IMAGE, "image_id", "(unused)" },
{ GIMP_PDB_DRAWABLE, "drawable_id", "Drawable to draw on" },
{ GIMP_PDB_COLOR, "fgcolor", "Color to draw with"}
}
You may be required to take certain
parameters, depending on where in the menu you registered.
You may ignore them once you get them, but they will be passed
to you, so you must accept them nonetheless. (app/plug-in.c,
plug_in_handle_proc_install):
FIXMEsource ref
Menu locations and required parametersMenu Location#Parameter typeDescription<Toolbox>0INT32run mode<Image>0INT32run mode1IMAGEID of current image2DRAWABLEID of current drawable<Load>0INT32run mode1STRINGFIXME
FIXMELoad string2STRINGFIXME
FIXMELoad string<Save>0INT32run mode1IMAGEID of current image2DRAWABLEID of current drawable3STRINGFIXME
FIXMESave string4STRINGFIXME
FIXMESave string
You may take any parameters you like in addition to the
ones required. The required parameters must come first and in
order, however.Declaring return values works much the same way, with
one note: Your procedure will have at least one return value
(a status code), but that should not be counted in your
nreturn_vals or included in your GParamDefreturn_vals.The Run Procedure
/* called to run a procedure the plug-in installed in the
* procedure database.
*/
typedef void (* GimpRunProc) (gchar *name,
gint nparams,
GimpParam *param,
gint *nreturn_vals,
GimpParam **return_vals);
The run procedure is where the action begins. Its
responsibilities include making sure the plug-in was called
correctly and setting return values, as well as making sure that
your plug-in does whatever it is that it's supposed to
do.&gimp; 1.1 Compatibility NoteIn &gimp; 1.1, the run parameter is always called with nparams == 3, when called in
the normal interactive fashion (plug_in_callback,
app/plug_in.c).
FIXMEsource ref
This differs from &gimp; 1.0 behaviour, where nparams was
equal to whatever it was set to upon installation of the
procedure in the query function.GimpParam
struct _GimpParam
{
GimpPDBArgType type;
GimpParamData data;
};
union _GimpParamData
{
gint32 d_int32;
gint16 d_int16;
gint8 d_int8;
gdouble d_float;
gchar *d_string;
gint32 *d_int32array;
gint16 *d_int16array;
gint8 *d_int8array;
gdouble *d_floatarray;
gchar **d_stringarray;
GimpParamColor d_color;
GimpParamRegion d_region;
gint32 d_display;
gint32 d_image;
gint32 d_layer;
gint32 d_layer_mask;
gint32 d_channel;
gint32 d_drawable;
gint32 d_selection;
gint32 d_boundary;
gint32 d_path;
gint32 d_unit;
GimpParasite d_parasite;
gint32 d_tattoo;
gint32 d_status;
};
Note that GimpParamData is a union, not a structure. It
only holds one value at a time.Return valuesIt's expected (in app/procedural_db.c
FIXMEsource ref
that you return a status code as the first return value (the
zeroth in C land). That's a GimpPDBArgType of
GIMP_PDB_STATUS, and a value from
GimpPDBStatusType
(GIMP_PDB_EXECUTION_ERROR,
GIMP_PDB_CALLING_ERROR,
GIMP_PDB_PASS_THROUGH,
GIMP_PDB_SUCCESS), or
GIMP_PDB_CANCEL).
ReviewWhat every plug-in needs:#include <libgimp/gimp.h>PLUG_IN_INFOMAINA query function, with a call
to gimp_install_procedure.A run function, setting a status code return value.Run: More detailsWe've said what's required. Now, what's a good idea?
This section previously contained some well-intentioned
practical advise on how to implement what you just learned, but
it was so terribly written that I can't bear to bring it back.
So for learning about implementations, I'm afraid you'll be
much better off reading source code until
this gets re-written.Move on to the next section to learn more
things…Working with the ImageA plug-in is of limited use if it has nothing to do with
the image. In this section, we explore the exciting world of the
&gimp; image hierarchy, and learn how to manipulate it.Intro to Images
In the beginning, there was Wilber, Wilber the
gimp. The graphic was without form and void, and darkness
was upon the face of the desktop, and the Spirit of Wilber
was moving over the face of the bitstream.And Wilber said,
<Toolbox>/File/New, and there was an
image. And Wilber saw that the image was good, and Wilber
separated the image into drawables. And Wilber looked down
at what he had wrought, and Wilber said, Oh
golly.
For Wilber had made the drawables of the layer according to
their kinds, and the drawables of the channel according to
their kinds, and the drawables of the mask according to
their kinds …
… or you could look at it the other way around. We
have all sorts of silly things like masks, channels, and layers,
but they're all just a bunch of pixels that can be drawn on, so
we treat them much the same and lump them all in to the category
of drawables. And an image, then, is just what
you get when you put some drawables together.Most plug-ins care suprisingly little about these images.
After all, it's the bunch of pixels on the drawable most of them
are playing with. In any case, the most complex data structure
a plug-in uses for an image is an integer (gint32),
a simple ID by which the &gimp; knows that image.Drawables make life much more exciting. You have to stay
on your toes about which data type a function uses, a
gint32 for the drawable's ID, or a
GimpDrawable, or a pointer to one. Here's the
GimpDrawable type (from &gimph;):GimpDrawable Definition
struct _GimpDrawable
{
gint32 id; /* drawable ID */
guint width; /* width of drawble */
guint height; /* height of drawble */
guint bpp; /* bytes per pixel of drawable */
guint ntile_rows; /* # of tile rows */
guint ntile_cols; /* # of tile columns */
GimpTile *tiles; /* the normal tiles */
GimpTile *shadow_tiles; /* the shadow tiles */
};
(Don't worry about the tile fields, you shouldn't have to
deal with those directly.)One may obtain a GDrawable from a drawable's
ID by the call GimpDrawable* gimp_drawable_getgint32
drawable_ID
which allocates and initializes the GimpDrawable for you, and
then returns the pointer.When you see a layer ID or
somesuch, this is really a drawable ID which happens to belong
to a layer. You may use it anywhere a drawable ID is called
for.Origins of CoordinatesIf you were looking at a spot on the &gimp; image, you
might choose to describe its location as the distance from the
origin of the image, from the origin of the layer, or from the
origin of the current selection.&gimp; chooses to measure coordinates from the upper-left
corner of the drawable (the drawable is usually a layer). If
you want to know about the location of the selection or the
layer offset, use the following calls (&gimph;):Functions to obtain coordinates.
/* Find the bounding box of the current selection in relation to the
* specified drawable. Returns TRUE if there is a selection. */
gint gimp_drawable_mask_bounds (gint32 drawable_ID,
gint *x1,
gint *y1,
gint *x2,
gint *y2);
/* Returns the offsets of the drawable. */
void gimp_drawable_offsets (gint32 drawable_ID,
gint *offset_x,
gint *offset_y);
Pixel RegionsThe method through which a plug-in accesses a drawable is
by way of what's known as a pixel
region.Before working with a pixel region, initialize it with the
following call:void gimp_pixel_rgn_initGimpPixelRgn* prGimpDrawable* drawableint xint yint widthint heightint dirtyint shadowdirtyA dirty tile is one that
has been changed. Tiles that are not dirty won't be written
back to &gimp;, whereas dirty ones will be. Initializing a
pixel region as dirty indicates to
gimp_pixel_rgns_process that it should
treat tiles in that region as if you've dirtied them.
shadowShadow tiles are merely an indication of the
desire to use a temporary buffer for writing in
to, says Peter. The advantage of using
shadow tiles are that A) you won't muck up the original
image, B) undo is handled properly, and C) the
modifications to the image are correctly masked by the
selection.In short, if you're writing to a pixel region, the dirty
and shadow flags should be TRUE, TRUE. If you need a clean copy
to read from, use FALSE, FALSE. TRUE, FALSE can be used for
writing directly to the image (not recommended), and FALSE, TRUE
could be used to read from shadow tiles that you've just written
to (possibly when using a multi-pass algorithm of some sort, as
in gauss_iir.c).There are calls for pixel_rgn_get_pixel, row,
col, and rect, which
grab data from the image and dump it into a buffer that you've
pre-allocated. And there are set calls to match. Look for "Pixel
Regions" in gimp.h.Note that these calls are relatively slow, they can easily
be the slowest thing in your plug-in. Do not get (or set) pixels
one at a time using
pixel_rgn_[get|set]_pixel if there is any
other way. Tips for improving efficiency are in the next chapter.Data formatThe data in your buffer depends on the image
type. Grayscale is an array of values. Grayscale-alpha has gray
value, alpha value, gray, alpha, etc. RGB and RGBA are just
that.Drawable mergin' and stuffOnce your plug-in is through munging the drawable, it has
to go through the process of making sure &gimp; has been brought
up to date. That sequence typically goes something like
this:Tidying up dirty drawables.
GimpDrawable *drawable;
/* . . . */
/* Ensure any dirty tiles are flushed to GIMP. */
gimp_drawable_flush (drawable);
/* Merge in what you've written to the shadow tiles.
If the second arguement is TRUE, the action will be undoable. */
/* Without this, anything you've written on the shadow tiles may be lost,
and drawable will be filled with uninitialized memory instead. */
gimp_drawable_merge_shadow (drawable->id, TRUE);
/* Update a portion of a drawable you've modified.
Updates the displays and drawable previews. */
gimp_drawable_update (drawable->id, x1, y1, width, height);
/* Flush the updates to the on-screen displays. */
/* (Not always desirable when called non-interactively.) */
gimp_displays_flush();
/* And if you're all done with the drawable, free the memory
allocated by gimp_drawable_get, and any tiles the drawable was using. */
gimp_drawable_detach(drawable);
More on SelectionsSelections are drawables too.
gimp_image_get_selection(image_ID); returns
the drawable ID of the selection mask.FIXME: Hmm, selection mask's 0,0 is drawable_mask_bounds'
x1,y1, izit? Also find out what feathered/anti-aliased
selections mean to us.See also: Appendix A: Premultiplied AlphaMiscThere are many joyous functions for the handling of
selections and layers and whatnot, which you may find by reading
gimp.h or using the db_browser. One that I should warn you about
is adding new layers to images: A layer created with
gimp_layer_new must still be added to the
image with gimp_image_add_layer before it
will do any good. Be sure you pass the same image ID to both
functions. And don't create layers without an alpha channel that
aren't background layers if you're not looking for
trouble.Efficient Image Handling: TilesWhether you knew it or not, lots of blood, sweat, and tears
have gone into making the modern &gimp; a tile-based graphics application. And no, that
doesn't have anything to do with the Tile of the
Day. What does it mean?Well, our graphics are two dimensional, but the memory
they're stored in is accessed by a one-dimensional index. The
usual approach to storing a graphic is to store the whole thing as
one long array, stringing one row on after another. This works
fine, until your images get rather large. Say you have a 1000 x
1000 RGBA layer, that takes 4 MB. Drawing a vertical line down the
image requires loading the entire thing into active memory, every
row from top to bottom.&gimp;'s approach is to break the image up into a series of
tiles. Now when you draw that vertical line, only the affected
tiles need be in memory.What's that mean to the user? Smoother handling of large
images, hopefully. What's that mean to you, the plug-in developer?
It's just something to keep in mind if you're at all concerned
about the speed with which you communicate with &gimp;. If you can
view the world in a similar fashion, things go much smoother for
the two of you. Otherwise you'll be running around picking up
pieces from different tiles… Also, if it's practical for
you to work on a single tile at a time instead of the entire
image, you'll use less memory yourself.Tile CacheIf you're going through the image a row or column at a
time, you're repeatedly accessing the same tiles over and over
again. That means &gimp; keeps sending you the tile, you use
1/64th of the information on it, ask for the next tile over,
only to want that tile back again when you need the next
row. This is rather inefficient, and consequently, slow.One way to solve this problem would be to restructure your
plug-in so it's not so troublesome in what it requests—
we'll talk about that in a moment. But there's another way to
solve it which is often much easier, from the programmer's
prospective. And that's to use a tile cache.This tile cache is separate from &gimp;'s tile cache, and
is local to the plug-in. The plug-in will store tiles here after
receiving them from &gimp; (if there is room for them). That way,
the next time you need data from that tile, it's already handy.Enabling a tile cache is easy. You have a choice of two
calls. From gimp.h:void gimp_tile_cache_sizegulong kilobytesvoid gimp_tile_cache_ntilesgulong ntilesThe first sets the cache size in kilobytes, the second
sets the cache size based on number of tiles… more or
less. Here's what gimp_tile_cache_ntiles does
(libgimp/gimptile.c, v1.0.0):
gimp_tile_cache_size ((ntiles * _gimp_tile_width * _gimp_tile_height * 4) / 1024);
A couple things with this… The integer division by
1024 here may cause it to round down, which probably isn't a
good thing. Also, the multiplication by four assumes four bytes
per pixel, which isn't a good assumption if you're not always
dealing with RGBA images. In short, you may want to do these
calculations and call gimp_tile_cache_size yourself.How big a tile cache to make? As many tiles as you'll be
using at once. If you're going by row, for example, cache
however many tiles are in one row. If you're both reading from
tiles and writing to shadow tiles, double the size of the
cache. You can find out the tile size by calling
gimp_tile_width() and
gimp_tile_height().Stuff you Don't Need to KnowTile size is defined at compile time in app/tile.h. The
size 64x64 is optimal for an Intel x86 because their memory
page size is 4096 bytes (64x64x1). You could change the tile
size, but there are currently a few things which will break if
you do, because they have some assumptions built in.FIXME: Write about common data access methods, such as the
row-buffer technique.Tile IteratorsThe first time I looked at plug-in code, I crept bravely
in, until I hit a line that looked something like this:
for(pr=gimp_pixel_rgns_register(1,&dest_rgn);pr!=NULL;pr=gimp_pixel_rgns_process(pr))
at which point I ran away screaming.After a while, I came back, sat down, and found out it's
what Quartic refers to as a tile iterator. Its job is to go
through the pixel region one tile at a time. You do not have to
use this method, you may use the
pixel_rgn_[get|set]_ calls as described
above. But the reason it's useful is because a tile at a time is
the most efficient way for &gimp; to do things, and these two
functions take care of the messy stuff for you.gimp_pixel_rgns_register's first
parameter tells it how many pixel regions you're going to be
iterating over, followed by pointers to those pixel
regions. After some hocus-pocus, it returns a pointer which is
used by gimp_pixel_rgns_process.Looking back at that plug-in's code:Using the tile iterator.
GimpPixelRgn region;
GimpDrawable *drawable;
drawable = gimp_drawable_get(drawable_ID);
gimp_pixel_rgn_init (®ion, drawable,
x1, y1, (x2 - x1), (y2 - y1),
TRUE, TRUE);
for (pr = gimp_pixel_rgns_register (1, ®ion);
pr != NULL;
pr = gimp_pixel_rgns_process (pr)) {
/* Fun Goes On Here */
}
The upshot of all that
gimp_pixel_rgns_ magic is, if while in the
loop, you look back inside your region, you'll find all sorts of
goodies. region.data now holds the image data for the area
beginning at region.x,
region.y, with a width of
region.w and height
region.h. Here, take a look at the data
structure (gimp.h):
struct _GimpPixelRgn
{
guchar *data; /* pointer to region data */
GimpDrawable *drawable; /* pointer to drawable */
guint bpp; /* bytes per pixel */
guint rowstride; /* bytes per pixel row */
guint x, y; /* origin */
guint w, h; /* width and height of region */
guint dirty : 1; /* will this region be dirtied? */
guint shadow : 1; /* will this region use the shadow or normal tiles */
guint process_count; /* used internally */
};
To write to the image using this technique, all you have
to do is change region.data, provided that
you flagged your region as "dirty" (and hopefully "shadow" as
well) when you initialized it.User InterfaceFirstly, see the GTK Tutorial. This document does not and will not take
its place.libgimpuiNew Ground Being Broken. Word is that Mitch will have
some docs for us as soon as the set of widget
constructors in libgimp is really consistant
(2000-01-30).GimpConstraintFuncWhen you have have a drawable menu created for you,
&gimp; makes use of a constraint function to ask you if what
should be listed in the menu. This way you can filter out
drawables that are the wrong size, image, type, etc. From
gimpmenu.h:
typedef gint (*GimpConstraintFunc) (gint32 image_id,
gint32 drawable_id,
gpointer data);
GtkWidget* gimp_drawable_menu_new (GimpConstraintFunc constraint,
GimpMenuCallback callback,
gpointer data,
gint32 active_drawable);
For every image, _menu_new calls
the constraint function with the corresponding image ID and a
drawable ID of -1. If the constraint function likes that image
and returns TRUE, it's then called and asked about each
drawable in the image, one at a time. If the function returns
TRUE again, the drawable is added to the menu.gimp_dialogNew Ground Being BrokenInternationalisationInternationalisation (abbreviated I18N)
is the process of allowing your program to be viewed by users in
their native language. Daniel Egger and Marc Lehmann maintain
the documentation for I18N of &gimp; plug-ins.
The Help System…Standards…RaphLevienPremultiplied AlphaPremultiplied alpha is just a different way of representing
alphified pixels. If the separate alpha pixel is (r, g, b, a),
then the premultiplied alpha pixel is (ar, ag, ab, a).The reason why it's interesting is that linear combinations
of pixels (i.e. a1p1 + a2p2) work better in premultiplied alpha
space than in separate alpha space. For example, taking the 50/50 blend of white and transparent
works like this: White is (1, 1, 1, 1) and transparent is (0, 0,
0, 0) in both spaces. So the 50/50 blend is (0.5, 0.5, 0.5, 0.5).
In separated space, that's half-transparent
gray, but in premultiplied space, that's
half-transparent white, which is what you expect.Linear combinations of pixels occur in a lot of contexts,
including:
layer compositingblurring and sharpeninginterpolationscalingrotation, perspective, and other
transformations
and probably one or two others.The symptom of getting alpha wrong is gray fringes when you
work with transparent layers.ThreadingThis section is pretty bare, but Emil Briggs has started
work on threading some few plug-ins. He says he sees an 80% speed
improvement with a threaded version of guass_iir on his
multiprocessor machine. If there's no reason why your plug-in
couldn't process several areas simultaniously instead of
sequentially, consider taking a look at his
page and following his example.
&glossary;
&genindex;
This text was written in DocBook 3.1 (XML) format, under PSGML mode of XEmacs 21. Output was produced with jade version 1.2.1, using Norman Walsh's DocBook DSSSL
Stylesheets.