Skip to content

Conversation

@Jehan
Copy link

@Jehan Jehan commented Nov 26, 2025

Hi!

We are using libmaxflow in GIMP for a new tool (still marked experimental) for quick selection of objects. Unfortunately the tool is still somewhat slow, especially if we start working on bigger files and if not in "Performance" power mode for instance, or simply with older hardware. I had experience of waiting for 10 to 15 seconds and 90% of the waiting happens inside g->maxflow().

Now we'd like to work on performance and maybe I'll propose some patch. But in the meantime, we also have to accept that the bigger the image and slower the hardware, the higher are chances of slow rendering and it is acceptable. The problem still is that when you wait 10 or 20 seconds, if you don't know where you are in the processing, it feels very slow, and worse, the GUI won't be responding anymore, which will appear "frozen" and often desktops would show the infamous popup "GNU Image Manipulation Program is not responding" with the option to kill the process. Bottom line: GIMP feels broken.

The solution to this is to show progression information, which first shows where the rendering is at, and the GUI is not frozen anymore, no popup appears, etc. In fact even 20 seconds of rendering doesn't feel too long (when someone works on very big images, they are aware things may take longer and as long as they get progression feedback, they are not worried of being in some infinite loop bug!).

The submitted API does not change any existing API, but suggests an alternative to calling g->maxflow() which does the processing in one block (and we just have to wait without info). Instead, we can process like this now:

float progress;

graph->maxflow_prepare();
while (graph->maxflow_compute (&progress))
  gegl_operation_progress (operation, progress, (gchar *) "");

Basically maxflow_compute does the same as maxflow() except it returns regularly (but not too often either) with some progression value (between 0.0 and 1.0), and the calling program can do something with it (updating a GUI progression widget like in GIMP, or showing progression information in a CLI, etc.).

Here is what the tool looks like when using this new API in GIMP: https://peer.tube/w/nqPXSWgD7PxM98R3osZy99

The thing to notice is the small green circle progression info saying "Selecting" when the tool works. This is only possible with this new API. Also note that it's quite fast on this demo image, but when I worked with bigger images, I really had cases where it took over 10 seconds inside maxflow() and where the GUI was frozen, ending up with the "GIMP is not responding" popup. When you get this, the tool feels dreary.

gnomesysadmins pushed a commit to GNOME/gimp that referenced this pull request Nov 26, 2025
This change won't do much right now, using upstream libmaxflow (though
it won't hurt either). It will really show its usefulness together once
this patch will have been merged in libmaxflow:

gerddie/maxflow#8

… then once done, I will push also a small update in "gegl:paint-select"
code on GEGL repo, which will in turn report the progression as reported
by libmaxflow.

This is particularly needed for big images on limited hardware, which is
when the current algorithm or its implementation will start showing some
weakness. I had cases (on 4000×3000 images in Balanced power mode) where
the processing inside graph->maxflow() could take more than 10 seconds,
the GUI would look frozen and the desktop would warn you through a popup
that the software "is not responding" (with the option to kill the
process). Furthermore without any kind of feedback, you have no idea if
processing will be soon finished or if it will take 10 minutes, or 1
hour, or even if you may be stuck in some infinite loop. In such
conditions, even 10 seconds actually feel long and the software appear
broken.

But when you have the progression feedback, you see that processing is
soon finished, and when working on huge images, you may expect that some
things may take longer than others. In such a case, even longer time may
actually feel very acceptable.

Note: an alternative to show progression would have been to use a
GeglProcessor, but apparently it gets its progression status a different
way, by cutting the image into smaller pieces. This doesn't work with
"gegl:paint-select", or at least its current implementation. Using the
"progress" signal works fine though.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant