maxflow: add methods to get progression feedback while computing.#8
Open
Jehan wants to merge 1 commit intogerddie:masterfrom
Open
maxflow: add methods to get progression feedback while computing.#8Jehan wants to merge 1 commit intogerddie:masterfrom
Jehan wants to merge 1 commit intogerddie:masterfrom
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:Basically
maxflow_computedoes the same asmaxflow()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.