Show percentage progress on syncing progress bar

[ayanes]

It kind of helps to see directly the % complete without pointing the right bottom corner

[laanwj]

The progress bar itself is meant to give a rough visual indication of the sync progress. We used to have a percentage in the progress bar in the past, but it was removed and replaced by a number of blocks because the percentage gave a sense of precision that is not there.

[ayanes]

IMHO the percentage really helps the user to estimate the pending blocks, the number is too messy. Check the example:

http://i.imgur.com/QF0GP.png

[laanwj]

Another thing is that when the client is restarted after some time of inactivity, it will have fallen a few blocks behind but always show 99.X% done, which is confusing (99% of what?).

[Diapolo]

I support @laanwj, no changes there, as we had more than 1 discussion on that progressbar. I consider the current look and feel as the best compromise.

[ayanes]

The 99% issue then must be present at:

https://github.com/bitcoin/bitcoin/blob/master/src/qt/bitcoingui.cpp#L533

Probably it gets calculated wrongly when the client continues syncing.

Anyway, closing it.

[laanwj]

No, it doesn't get computed wrongly. The underlying (psychological) issue is that the progress bar makes the sync look like a normal linear download of a fixed-size file in the mind of users. Adding a percentage adds to this illusion.

Even though in reality it fetches a growing tree structure of uncertain (at least to any one observer) size, of which only the longest path is significant.

So there is a cognitive gap, and I would applaud efforts to visualize the progress in an intuitive way that doesn't cause this inherent confusion. However this is likely much more complex than can be solved by hair splitting over whether to show a percentage or not, or where to start counting.

Quite possibly effort is better spent solving the underlying issue that frustrates users: having to wait at all! For example, developers are working on making the client start in SPV mode, so it is immediately usable, then fetching the block chain in the background.

[luke-jr]

Maybe using a logarithm for the visual bar would make sense. For text, counting the nines might work: "4 nines up to date!" :P

[L2G]

Forgive me if this is a repeat, but I'm still new here. :-)

Did anyone ever talk about just starting the progress bar over at the left whenever a resync of more than two or three blocks has to happen?

If someone has Bitcoin-Qt running continuously, I don't think it can get out of sync more than two or three blocks, can it? But if it's more than that (10 blocks, 50 blocks, 500 blocks...) then putting up the progress bar and starting from empty again is more what a user would expect, IMHO (I know it's what I would expect). I know the 100% point is unpredictable and there will be cases where the bar fills up all the way, then has to change to a valueless active state, but it's still better than throwing up a bar that always looks like it's a pixel short of being full, every time.

[laanwj]

Yes, that has been discussed many times. It has even been implemented for a
while, because I thought it was a good idea back then, but it made users
complain that the sync had restarted from scratch. So it was reverted.

[Diapolo]

@L2G The next version will not meassure in blocks anymore on the progressbar anyway, it is a time-based solution, that tells how many weeks, days, hours your client is behing the network. It will be included in 0.8.X.

@laanwj Sorry to be OT, but any news about the refactorings or my small open pulls + the ones we ACKed :)?

[L2G]

@laanwj, is that patch that you talked about still around somewhere? I'd love to play with it!

[sipa]

@L2G There is probably no feature that has caused as much discussion as that progress bar already. Different systems have been tried already, and been reverted. IMHO, it just shows that a progress bar is not the correct way to represent this information. Current git head shows "N days behind" for example, instead of a percentage, which is certainly more useful. It also bases the progress calculation on the number of (estimated) transactions, rather than the number of blocks (which is very fast initially, and very slow at the end).

[L2G]

All I am talking about is this:

(1) The app notices that data is out of sync.
(2) It displays a progress bar that starts empty.
(3) It syncs up and allows the progress bar to move from left to right.
(4) When it is done, it hides the progress bar again.

It doesn't matter to me whether it counts blocks, time, pink elephants, moonbeams, etc. I would like to see a bar that shows how much closer it is to being in sync from the time it started syncing. Surely that alone isn't a controversial feature?

[L2G]

And if it is a controversial feature... why not just default to having it turned off, and give the user the option of turning it on?

[gmaxwell]

I believe that adding an option, which must be maintained, tested, etc just to control how a confusing progress indicator is displayed would not be a good use of time or testing resources.

[L2G]

I probably came off sounding like a snot about this, and I apologize. I won't belabor the idea.

[gmaxwell]

@L2G Thanks for taking a step back there— it can be hard working on this when there are so many LOUD opinions about. People do have your wishes in mind here— and you're certainly not the only person who has expressed similar ones—, and at least if someone sees a way to make this work better for everyone that they're confident won't have issues, it'll make its way in eventually.