Skip to content
This repository was archived by the owner on Nov 28, 2019. It is now read-only.

Conversation

rck109d
Copy link

@rck109d rck109d commented Oct 17, 2013

This change addresses the issue where a progress bar of less than 100 pixels will show incorrect text in some situations.

I understood the problem to be that for bars with fewer than 100 pixels comparing ratios between bar pixels to the percentage of the represented fraction will not always be equal.

For example the ratio 1 / 13 as shown on a bar of 45 pixels:
1/13 = 0.076... ~= 8%
45 * (1/13) = 3.4... ~= 3 pixels
3 pixels / 45 pixels = 0.066... ~= 7%
The code was expecting the 7% to equal 8% before terminating.
Because this condition never happens the interval function keeps running and overwrites the progress bar text even after future changes!

At first I thought different rounding would resolve it (round the 7.6 down to 7 and the 6.6 up to 7). However I think that won't work in every case. I now prefer the included solution also because it's easier to understand.

The interval function is now named intervalUpdate and it stores the previous percentage of pixel transition progress in intervalUpdate.prev_percentage and compares this to current_percentage. If these two values are equal it is assumed that no more progress is being made and so the interval will terminate.

This change addresses the issue where a progress bar of less than 100 pixels will show incorrect text in some situations.

I understood the problem to be that for bars with fewer than 100 pixels comparing ratios between bar pixels to the percentage of the represented fraction will not always be equal.

For example the ratio 1 / 13 as shown on a bar of 45 pixels:
1/13 = 0.076... ~= 8%
45 * (1/13) = 3.4... ~= 3 pixels
3 pixels / 45 pixels = 0.066... ~= 7%
The code was expecting the 7% to equal 8% before terminating.
Because this condition never happens the interval function keeps running and overwrites the progress bar text even after future changes!

At first I thought different rounding would resolve it (round the 7.6 down to 7 and the 6.6 up to 7). However I think that won't work in every case.  I now prefer the above solution also because it's easier to understand.

The interval function is now named `intervalUpdate` and it stores the previous percentage of pixel transition progress in `intervalUpdate.prev_percentage` and compares this to `current_percentage`.  If these two values are equal it is assumed that no more progress is being made and so the interval will terminate.
terminating a transition when the `current_percentage` is greater than `percentage` will make the text changing end prematurely.
@rck109d
Copy link
Author

rck109d commented Oct 17, 2013

the add-on commit prevents the text updating interval from terminating prematurely in the case of starting high and going low (e.g. 90% to 10%).

when the progress bar transition comes to rest that's when we're done.  no need for superfluous check.
@minddust
Copy link
Owner

@rck109d thanks for diggin in! will check this on sunday - got a lot of work to do right now.

@minddust
Copy link
Owner

minddust commented Aug 2, 2014

@rck109d long time no see. sorry about that.

without testing - i would say it could be for slow transitions, wide bar and fast refresh cycles that your condition is true even before reaching the final value. that's one of the reasons why i tested against percentage.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants