Thanks, Simon. It is really thorough and helpful. On Tue, 7 May 2019 at 13:16, Simon Budig <simon@xxxxxxxx> wrote: > Hi Ahmad. > > Ahmad Nouralizadeh via gimp-developer-list (gimp-developer-list@xxxxxxxxx) > 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@xxxxxxxx http://simon.budig.de/ > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > 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@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
