Thanks
By default, batch processing, as the name implies, waits unless starting processes in separate instances is enforced (only then does it immediately proceed to the next line).
But you can also force to wait if the default behavior the other way around:
NOTES: Each additional Gimp command line will be executed only after gimp.exe console is closed and in Windows cmd.exe console the batch process is continued (in case by pressing N key for No - to do not cancel batch operation)
Of course it is possible but syntax-technically and clearly disastrous, especially because many arguments per command line will follow, which have not been implemented here yet:
Indirect multitasking (with more single processes) is possible, but then unfortunately not for the same pictures.
Nevertheless thank you very much for joining!!!
(09-25-2022, 11:57 AM)Ofnuts Wrote: If Gimp is already started when you call it from a shell, then the arguments are passed to the already loaded instance.Unfortunately, this is not the case for me on Windows: regardless of whether the tool is already running in the foreground, unfortunately a new separate process instance is currently always executed.
(09-25-2022, 11:57 AM)Ofnuts Wrote: But of course each "gimp" command in your script will run bow nearly instantaneously because it returns before the work is done, so if each needs the result of the previous one that won't do it.No, in "batches" is this behavior as you described not usual and Windows Batch Scripts not either unless each gimp command line is executed on the beginning as follows to force a new process instance:
Code:
START "" "%gimp%" …By default, batch processing, as the name implies, waits unless starting processes in separate instances is enforced (only then does it immediately proceed to the next line).
But you can also force to wait if the default behavior the other way around:
Code:
START "" /WAIT "%gimp%" …NOTES: Each additional Gimp command line will be executed only after gimp.exe console is closed and in Windows cmd.exe console the batch process is continued (in case by pressing N key for No - to do not cancel batch operation)
(09-25-2022, 11:57 AM)Ofnuts Wrote: But the first thing to do to improve performance is to string your commands into a single script, and so call gimp only once.You certainly mean here "into a single command line", because considered as a "file" it is a single script - in my case from this point of view it is the same script, but in another context it is several, depending on how it is viewed.
Of course it is possible but syntax-technically and clearly disastrous, especially because many arguments per command line will follow, which have not been implemented here yet:
Code:
"%gimp%" -i -b "(BatchCropToContent \"*.%FileExtens%\")"
"%gimp%" -i -b "(scale \"*.%FileExtens%\")" "Arg1" "Arg2" "Arg3"
"%gimp%" -i -b "(rotate \"*.%FileExtens%\")" "Arg1" "Arg2" "Arg3"(09-25-2022, 11:57 AM)Ofnuts Wrote: You can also use new instance to have separate instances of Gimp and make them run in parallel (I don't know how to do that in Windows) so if you process several files you can use all your processors (Gimp is still essentially single-thread).All right, but that is not the described problem here. Here now it doesn't matter that the tool is not multitasking on a single instance.
Indirect multitasking (with more single processes) is possible, but then unfortunately not for the same pictures.
(09-25-2022, 11:57 AM)Ofnuts Wrote: There are also a couple of options to the Gimp command …Yes, I see, but this does not help by far to solve that main problem described here.
Nevertheless thank you very much for joining!!!