Remove draw limiting from the ProgressBar state

[djc]

We now have rate limiting in the draw target, which is takes care
of most of the costs of drawing. Limiting earlier is not as
helpful in terms of performance, and reduces accuracy.

[chris-laplante]

I think ProgressState::update needs to check more than just pos to determine whether or not the draw should occur. For example I think ProgressBar::tick() broke because the pos didn't change, but tick did.

[djc]

What about if we just always update?

[chris-laplante]

What about if we just always update?

I feel like there is still a hole in the design. LeakyBucket should (IMHO) only come into play when pos and/or tick change. Any other change to ProgressStyle (such as changing the message, prefix, style, e.g.) or hiding/showing the progress bar should not be subject to rate limiting since they are important visual changes.

Granted, I have not encountered this issue, but I think they exist in the code.

[chris-laplante]

However in the meantime, I think this change is good

[djc]

I feel like there is still a hole in the design. LeakyBucket should (IMHO) only come into play when pos and/or tick change. Any other change to ProgressStyle (such as changing the message, prefix, style, e.g.) or hiding/showing the progress bar should not be subject to rate limiting since they are important visual changes.

I think this is already how it works today. The condition for returning a Some(Drawable::Term { .. }) for ProgressDrawTargetKind::Term is force_draw || has_capacity (where has_capacity is the outcome of the LeakyBucket limiter) -- and force_draw is what most things like changing the message/prefix/style are already using.