Thanks, Simon. It is really thorough and helpful.

On Tue, 7 May 2019 at 13:16, Simon Budig <> wrote:

> Hi Ahmad.
> Ahmad Nouralizadeh via gimp-developer-list (
> 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
> --
> _______________________________________________
> gimp-developer-list mailing list
> List address:
> List membership:
> List archives:
gimp-developer-list mailing list
List address:
List membership:
List archives:

Reply via email to