Re: [Gimp-developer] A Process for Each Plugin

[Simon Budig <simon budig de>]

Hi Ahmad.

Ahmad Nouralizadeh via gimp-developer-list (gimp-developer-list gnome org) wrote:
> I wonder why GIMP spawns a separate process for each plugin (e.g., by
> calling g_spawn_async() @app/plug-in/gimpplugin.c:368). For example, I
> opened an image and the contents of the image was loaded in the memory of
> process gimp. But when I applied a VanGogh filter on the image, a new
> process, van-gogh-lic, started and processed the image contents.

Yes, this is completely as designed and expected.

> - Why another process is forked? AFAIK, a fork is used only for the cases
> when the tasks of the parent and child are completely different.

Having the tasks in different processes has a few advantages:

 * plugins can be small completely separate entities with a very
   specific small scope. This makes them easy to understand and fast to
   develop
 * buggy plugins don't case the main gimp process to crash and burn
 * they work independently of the actual GIMP version.

An alternative would be to create plugins as shared libraries that get
linked into the main application. This might have some complications
with the build process as well as the intricacies of the dynamic
linking. But it would be doable.

> - How does van-gogh-lic access the contents of the image, while it is
> loaded in its parent (i.e., the gimp process)?
> - I also traced the parent process using Pin, which showed that during the
> application of the filter, many accesses were made by gimp. Why?

Plugins use libgimp, which takes up the task of communication with the
main application. There is quite some back and forth between these two
processes using an IPC mechanism. A plugin that invokes a PDB function
basically asks GIMP to do the task.

The actual image data is transferred via shared memory: The two
processes work on the same pixel data, which avoids expensive copying of
data.

In the future more image operations will become GEGL-Ops, This is indeed
a step into "dynamic linking" area, but hopefully the GEGL
infrastructure is good enough to make it reasonably easy to wrap the
head around.

I hope this helps,
         Simon
-- 
              simon budig de              http://simon.budig.de/