Performance boost and simpletest update

[FoamyGuy]

This addresses concerns raised in #7.

The new progress drawing strategy will try to only change pixels that need it based on the new progress value and the previous progress value.

It turned out that this library was suffering from the same issue going both directions. Running a loop backward through progresses like this:

    for current_progress in range(20, -1, -1):
        print("Progress: {}%".format(current_progress * 0.05))
        progress_bar.progress = current_progress * 0.05
        time.sleep(0.01)

would result in a similar effect of the drawing slowing down as the progress approaches 0.0 I have implemented the new strategy in both cases of progress moving up and progress moving down.

When the progress is moving down the library previously would fill the "empty" portion of the progress bar from left to right so it looked like it was moving "the wrong way" I modified the behavior to fill emptiness from right to left so the progress bar appears to visually "empty" itself in reverse as it gets drawn.

I made one other tweak to the simpletest example script to change it from adding floating point numbers to instead count by integers and multiple by a decimal to get the current progress. This lets us avoid a floating point precision issue that resulted in the progress sometimes getting set to things like 0.54999999 instead of 0.55

[gfbarros]

This outputs 0 -> 1%. I changed it to
print("Progress: {}%".format(current_progress * 0.05 * 100))

[FoamyGuy]

Good catch thank you. I'll push a new commit to fix this soon.

[gfbarros]

I don't entirely understand the range ending in 21 as 100% It's more intuitive to me for 100% to be... well... 100 :)

[gfbarros]

Ok, I get what you are doing now that i've read through it a few times. I think the prior example was more intuitive to a newbie (myself) as it made me think in percentages but it does expose the float issue. Maybe leave both in as examples?

[FoamyGuy]

This change allowed us to count by integers instead of floating point numbers. There was some more discussion about it in the #circuitpython channel on discord this morning if you are interested in learning more about it. http://adafru.it/discord

I think you are right though it would be more clear if it ended on 100. however if it counts by 1 it will be somewhat slower than it is now. we can step by 5 in the range loop though to get the same speed. I'll make this change too. Thank you.

[gfbarros]

Being just the example, I think the slower counting to 100 makes more sense. Maybe include a comment mentioning performance? Thank you for fixing this!

[gfbarros]

This looks great, thanks!

[gfbarros]

Sidebar: I wish the clear (progress_bar.progress = 0.0) was a blank instead of blacking out the progress bar in reverse :)

[FoamyGuy]

Sidebar: I wish the clear (progress_bar.progress = 0.0) was a blank instead of blacking out the progress bar in reverse :)

Yep I agree with that. I think it's a limitation of the way the progress is made with a bitmap currently. We have recently gotten a new way to draw shapes with vectorio I am looking into the possibility of drawing the progress bar with that instead of a bitmap. It may change the way it looks when its blanked out.

[tannewt]

Thank you!