maxflow: add methods to get progression feedback while computing. #8
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.