Multithread python plug-in?

[ChameleonScales]

My plugin performs a bunch of operations on dozens of large images which takes several minutes and only uses a single thread.

I'm wondering if there's a way to write code in the plug-in to allow for multithreading, e.g. by telling Gimp to open more instances of itself or any other way.

Is that possible?

[Ofnuts]

(02-07-2021, 06:46 PM)ChameleonScales Wrote: My plugin performs a bunch of operations on dozens of large images which takes several minutes and only uses a single thread.

I'm wondering if there's a way to write code in the plug-in to allow for multithreading, e.g. by telling Gimp to open more instances of itself or any other way.

Is that possible?

Never tried. You can spawn new threads and try (especially since you only "read" the images, what do you risk...).

However:

• If in Python you can model things with threads, in practice your threads never run in parallel due to the GIL
  
• Maybe the problem is with I/O and adding more CPU isn't going to help
  

If the problem is indeed CPU, another approach would be to

• Start a Gimp instance (without and image or that runs a script with a sleep delay to just remain around)
  
• Start several parallel shell tasks that will each call Gimp to run your script on one image
  

Or even run several distinct instances of Gimp in paralllel (use gimp -n).

[ChameleonScales]

Quote:especially since you only "read" the images

I'm not talking about the same plug-in as in the other thread. The one I'm thinking of here also performs image operations and saves the xcfs.

Quote:Start several parallel shell tasks that will each call Gimp to run your script on one image

That seems like a good plan, although I don't know yet how to run a gimp plug-in script from the terminal (haven't searched yet either). Also, since my plug-in has a dialog with properties that have to be set, I assume I'd have to make the same dialog outside of Gimp using GTK so that the user doesn't have to set the same parameters on each Gimp instance and those settings could be fed in all the instances.
If I can do this it would be quite performant on a beefy machine.

[Ofnuts]

(02-08-2021, 04:05 PM)ChameleonScales Wrote:

Quote:especially since you only "read" the images

I'm not talking about the same plug-in as in the other thread. The one I'm thinking of here also performs image operations and saves the xcfs.

Quote:Start several parallel shell tasks that will each call Gimp to run your script on one image

That seems like a good plan, although I don't know yet how to run a gimp plug-in script from the terminal (haven't searched yet either). Also, since my plug-in has a dialog with properties that have to be set, I assume I'd have to make the same dialog outside of Gimp using GTK so that the user doesn't have to set the same parameters on each Gimp instance and those settings could be fed in all the instances.
If I can do this it would be quite performant on a beefy machine.

There are simpler ways to ask parameters than a full GTK dialog  in a shell script, for instance using zenity. But as a person who deals with Linux servers all day long, please don't, or at least also allow regular script parameters, because you often want ot run the script with slightly different parameter, and the fastest way is to retrieve the previous command line (cursor up) and edit the parameters, instead of having to reenter all values in "friendly" dialogs.

To call you script from a command prompt, see this exemple.

[ChameleonScales]

Quote:To call you script from a command prompt, see this exemple.

Coool, thanks!

Quote:There are simpler ways to ask parameters than a full GTK dialog  in a shell script, for instance using zenity.

True. I use zenity and yad sometimes but I've been starting to learn some GTK to prepare myself to make some more complex stuff in the future. Spent a whole evening making a dialog that would've taken 5 lines of yad. That was fun.

Quote: But as a person who deals with Linux servers all day long, please don't, or at least also allow regular script parameters, because you often want ot run the script with slightly different parameter, and the fastest way is to retrieve the previous command line (cursor up) and edit the parameters

I agree and I'll keep that in mind. For the use I'll have with it, a dialog is great so I'll still make one but will also make it so you could do it all from the terminal when I release the plug-in into the wild.