Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar? 736

hyperorbiter writes "How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?

Comments Filter:
  • by Anonymous Coward on Wednesday February 13, 2013 @12:17AM (#42879229)

    Comment loading ...

  • Yes. (Score:5, Funny)

    by kc9jud ( 1863822 ) on Wednesday February 13, 2013 @12:17AM (#42879237)
    Yes it is. And to be fair, it's a lot more accurate than Nostradamus ever was.
  • by Punto ( 100573 ) <> on Wednesday February 13, 2013 @12:22AM (#42879273) Homepage

    There's probably a pantent for a "method or apparatus for an accurate display of progress", nobody wants to mess with that (but seriously most of my innacurate progress bars deal with unpredictable things like I/O, or non-uniform sets like loading textures and meshes and animations all together, so who knows how much time it will actually take to process the same ammount of data?)

  • by dotHectate ( 975458 ) on Wednesday February 13, 2013 @12:27AM (#42879335) Journal
    You know someone is going to take your suggestion literally as a tutorial on how to implement a progress bar - later they'll come back with some mystical crash always happening at 0%.
  • Physics! (Score:5, Funny)

    by ignavus ( 213578 ) on Wednesday February 13, 2013 @12:42AM (#42879479)

    You can work out where you are (% completed) or how fast you are going (rate at which the progress bar is growing), but not both at the same time.

    It's simple quantum mechanics.

  • by The Snowman ( 116231 ) on Wednesday February 13, 2013 @01:08AM (#42879703)

    Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.

    You mean like this one? [].

  • by PPH ( 736903 ) on Wednesday February 13, 2013 @01:59AM (#42880127)

    ... a functional progress bar in 5 years.

    No, wait. It seems to have stalled.

  • by ibennetch ( 521581 ) <[moc.liamg] [ta] [hctenneb]> on Wednesday February 13, 2013 @02:29AM (#42880273) Journal

    I think I prefer going backwards to what I once saw on (what I remember as) a Microsoft Office installation, probably 15 years ago. The progress bar ever so slowly crept upwards...98, 99, 100% done...then 101, and so on. It finally locked up somewhere after 140%.

  • by JonJ ( 907502 ) <> on Wednesday February 13, 2013 @03:09AM (#42880443)
  • by ae1294 ( 1547521 ) on Wednesday February 13, 2013 @05:15AM (#42881001) Journal

    This problem was solved a long time ago... I still wonder why people don't know how to code a proper progress bar...


    Setup bar, value set to 0%
    Create link-list of all files to transfer with their size in blocks, zeroed time in msecs, & Boleyn value for iftransfered.
    Transfer available buffer * 2, update link-list times for each file transferred and mark iftransfered true. Use following file selection method from link-list choices:
    Rand(Total files).
    iftransfered = True then +1 until false or (Total Files) reached.
    If (Total Files) reached then -1 until all files transferred = True.
    Calc buffered transfer & unbuffered transfer times using link-list data.
    Update untransferred files link-list times based on above using 71% weighting of unbuffered over buffered times.Update display
    Transfer 1x buffer update link-list & evail difference between first and second transfer. Adjust weighting using following:
    Pick random # between 1 and 661 + 42^2 * last weighting.
    Divide until less than 100.
    If less than 89 then random # above - sqrt42 * first weighting.
    Again divide until less than 100.
    If less than 41 then transfer 4x buffer. repeat buffered time weight calc. goto pick random 1 and 661 step.
    If above step repeats more than thrice adjust plank constant up by 11.11% & factor new weightings. Store in reg.
    If above above step repeats more than 7 times adjust plank constant down by 11.11% and factor new weightings. Store in reg.
    Update display, if greater than 100% than 100%.
    If number is irrational do 2D4 damage unto number until it becomes rational again. update display.
    Continue transfiguring & updating link-list and weights as above so as below.
    If time remaining goes negative check if users name begins with bob. Display Improper observer, recalc from start with different observer.
    If time goes infinite check on cat. If dead display Improper universal constant detected. Invert plank constant. recalc from start. Store regValue TimeFlow Inverse = True. Check at start to avoid problem. NOTE: program should check that user has not switched universes every x transfers or in background test transfer at idle.
    If above happens thrice then cthulhu re-entering universe probability approaches infinite. Halt transfer. Terminate user. display greetings...

    I've left out the easy stuff but this provides for a 99% correct est. Please note that the computer must be from 1 year in the future for this to exceed 87% correctness without causing time dilation within progress meter by blocks remaining^66 msecs. Check Mfg date at start and adjust time est accordingly.

    The above is copy-written and my not be used....

  • by telchine ( 719345 ) on Wednesday February 13, 2013 @07:08AM (#42881597)

    Sure step 5 of 12 might take way longer then the rest but at least it is honest. It also helps to tell the user what it is currently doing.

    Reticulating splines?

Do not underestimate the value of print statements for debugging.