It would be great if the G’MIC developers could review their code and support multi-threading for at least the more demanding filters, because otherwise they can’t be used in professional environments or trainings, where time is an issue.
One striking example is the filter Repair > Inpaint [patch-based]. It can deliver superb results, but even with images of modest resolution/size, simple operations can take minutes or hours, and this is not something like rendering a SFX scene of a Star Wars movie.
As a result (speaking from personal experience), I cannot demonstrate this filter (and some others) during talks or trainings, simply because it takes too long to render the result.
Maybe this is something you haven’t noticed, but most G’MIC filters actually use multi-threading for computing their result. Inpaint [patch-based] is one of the exception, but there is a good reason for that : the algorithm used here consists of iterative copy/pasting of patches that can’t be done simultaneously (one paste has a consequence on all the following). This is a single-threaded algorithm by nature, and there is very few we can do to change it.
Try Inpaint [multiscale] which uses a different inpainting algorithm that can be (and is) multi-threaded.
I use it all the time and it’s exhaustingly long every time.
In fact sometimes the manual method with the clone brush is faster, but it’s hard to know in advance.
Plus, since the Krita plugin doesn’t memorize the position of the selection, I have no choice but to wait without touching anything.
This basically means reimplementing most of the G’MIC fundations, including the CImg image processing library based on CPU multi-threading rather than GPU.
So yes, it’s theoretically, possible, but not by me. Reimplementing the same stuffs again, on GPU, just to gain more speed is definitely not in my plans.
If anyone is interested to give a try, just let me know.
