Report progress in ReplayBlocks while rolling forward

[promag]

Fixes #13303.

[promag]

Should only report each 5% for instance?

[Empact]

CWallet::ScanForWalletTransactions has an implementation that only reports every 1% 100 blocks.

[promag]

@Empact IMO the receiver is the one that should throttle, because he is the one that knows the resolution. Anyway, looks like ScanForWalletTransactions reports progress each 100 blocks, or am I wrong?

[Empact]

Yep you're right on ScanForWalletTransactions.

[GreatSock]

I think it should report every 1% change. But since changes less than 1% won't be visible, maybe check if the percentage have actually changed before updating. Calling ShowProgress 100 times should be fine right?

[promag]

I don't mind doing something like that...

But since changes less than 1% won't be visible

But how do you know? What if you have a progress bar with, for instance, 200px width? It should report 0.5%.

[GreatSock]

Right now ShowProgress seems to take an integer which means 1% changes won't be visible.

But I agree: ShowProgress should instead take a float(maybe even between 0 and 1) and then check if it should update by itself. This would probably be better since it can then choose to display the progress however it wants.

[promag]

Actually I was thinking in something like ShowProgress(int min, int value, int max).

[GreatSock]

I would personally prefer giving it a float since I feel like it would be more flexible. But then again, why not do both? We could just overload the function.

[jonasschnelli]

What is the best test plan to test this?

[DrahtBot]

The last travis run for this pull request was 60 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened.

[jb55]

Anything left to do here?

[laanwj]

utACK b16ab9a

[laanwj]

Anything left to do here?

Not really—I think the most important thing to review here is that divide by zero never happens.