icpfind reports progress every 250 cross matches.

[rew]

This is just fine for my current projects. For small projects it might update slightly too fast (too much useless overhead in painting the screen) while for a large project it goes a bit slowly.

This means that it depends on the size of the project how fast the updates come. But most of all the updates depend on how fast my CPU is. To make the software future proof, we should make it for example:

- set a timer to go off twice a second.
- in the timer set a flag.
- in the mainloop (e.g. every 1, 10 or 50 matches) check for the flag and print the progress if set. Reset flag.

(this is the most sure-fire way to prevent IO concurrency problems. ).

[tmodes (tmodes)]

icpfind is only a wrapper around the different control points detectors. It "simply" calls the detectors and waits for the results. It does not have access to the internal of the different control points detectors.

If the wish is for cpfind, I think cpfind reports enough progress. Also the matching phase is significant faster than the loading/remapping/detection phase; so I see no point in adding more progress indicators for matching.

[rew (r-e-wolff)]

Tomas, Currently the progress reporting is already much better than before: previously autopano-sift would update the gui continuously and the text output only every now and then. This resulted in lots of CPU time wasted for updating the screen, which could have better been used in working on finding my control points.

So, yes, it's quite reasonable, and works fine today. So it's a wishlist item.

The thing is, if my computer becomes 10 times faster, it will be updating the screen faster than I can see. That's useless. And even if it is only spending 5% of the time updating the screen, it could become 5% faster on a large pano a few years from now. That's why I suggest to use a time-based update frequency and not a "work progress".

If we turn it around. Suppose I were to run this on a 100 times slower computer (a 486). It would update at most only twice a minute. This leaves the user in the dark about the progress much too long. So the current "every 250 checks" works reasonable on reasonably modern hardware. But we can't say anything about the hardware from 10 years ago, or 10 years from now. I would prefer to change the software now to be future proof.

[tmodes (tmodes)]

Closing here: icpfind has no access to internal of other cp generators.
And cpfind is multi-threading. Implementing the proposed algorithm would require a lot of synchronization/blocking of different threads. This is wasting more cycles than it improves the behavior.

[rew (r-e-wolff)]

For a progress indicator, an off-by-one caused by insufficient locking does not matter.

I don't know how the threads could measure their progress. But simply incrementing a global variable (common to all threads) allowing a "progress-reporting-thread to inspect it and report it.

The "no locking" would mean you'd get an occasional off-by-one. (thread loads variable into CPU, increments it, other thread also increments it and first thread stores the result it incremented. Now one of the increments has been lost. As long as you spend say less than 1/1000th of the time
incrementing the counter, you are going to lose less than 1/1000th of the counts. Still totally unacceptable if it causes the program to hang, e.g. waiting for the counter to reach the end. But for progress reporting to the user: just fine.