Sign up now! · Forgot password?
RSS/Atom feed Twitter

A Process for Each Plugin

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

3 of 3 messages available
Toggle history

Please log in to manage your subscriptions.

A Process for Each Plugin Ahmad Nouralizadeh via gimp-developer-list 06 May 21:39
  A Process for Each Plugin Simon Budig 07 May 08:19
   A Process for Each Plugin Ahmad Nouralizadeh via gimp-developer-list 07 May 23:05
Ahmad Nouralizadeh via gimp-developer-list
2019-05-06 21:39:59 UTC (19 days ago)

A Process for Each Plugin

Hi,
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. - 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. - 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? Regards.

Simon Budig
2019-05-07 08:19:09 UTC (19 days ago)

A Process for Each Plugin

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/
Ahmad Nouralizadeh via gimp-developer-list
2019-05-07 23:05:53 UTC (18 days ago)

A Process for Each Plugin

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 (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/ _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list