hugin-devs team mailing list archive

[rew <684826@xxxxxxxxxxxxxxxxxx>]

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.

** Tags added: cpfind
** Tags removed: icpfind

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

Title:
  icpfind reports progress every 250 cross matches. 

Status in Hugin - Panorama Tools GUI:
  Triaged

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. ).