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
       Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/684826

Title:
  icpfind reports progress every 250 cross matches.

Status in Hugin:
  Won't Fix

Bug description:
  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. ).

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/684826/+subscriptions

_______________________________________________
Mailing list: https://launchpad.net/~hugin-bug-hunters
Post to     : hugin-bug-hunters@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-bug-hunters
More help   : https://help.launchpad.net/ListHelp

Reply via email to