Re: [Gimp-developer] 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 > -- > si...@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 > ___ 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
Re: [Gimp-developer] 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 -- si...@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
[Gimp-developer] 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. ___ 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
