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"
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.
** Changed in: hugin
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 findi
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 matchin
4 matches
Mail list logo
