551433 - Smoothly animate progressbar position

Status: ASSIGNED

(Toolkit :: UI Widgets, defect)

Description

[Markus Stange [:mstange]]

Attachment: wip

Instead of abruptly changing the progressbar position whenever its value is set we can smoothly animate to that position.

This patch does this by setting up an animation timing function in the setter of the "value" property. Then this timing function is periodically evaluated and the "animvalue" attribute is set to that value. When the animation is finished, the animvalue attribute is removed.
The animvalue attribute is only used for the appearance of the progressbar; its value is only used in nsProgressMeterFrame and in native theming. The value attribute keeps its current meaning and is always set to the unanimated target value.
The timing function is a cubic polynomial that keeps the ongoing animation's momentum at the start of the new animation and smoothly eases out to the target value.

This patch only animates when the value is increased, not when it's decreased. This probably makes sense in most cases because most progressbars only grow; decreasing their value usually means that they're reset, which should be instant.

However, there are times when even the growing animation is not appropriate, for example for the <video> playback position progressbar, where the animation will cause the white playback position line to get out of sync with the time bubble thing on top of it.

For these cases we need a way to say "set this value without animation". I'm not sure what's the best approach there: a setValueWithoutAnimation() method, or rather a usesAnimation property?

Also, do we want the animation on all platforms? I could imagine that it looks strange on natively-themed progressbars on Windows XP, for example.

Here are tryserver builds with this patch (and some others to make it work with the tab progressbar from bug 544818):
https://build.mozilla.org/tryserver-builds/[e-mail]-try-03c5062038c3/

Comment 1

[Markus Stange [:mstange]]

Attachment: testcase (works without patch)

Comment 2

[Neil Deakin]

Interesting, but it doesn't seem like something that should be used by default. I could see value in having a setValueSmooth type method perhaps, or a usesAnimation property as you suggest.

Is there a case where having smooth value adjustment is useful? If not, it may be more worthwhile to wait until a decent animation api is available, as the patch here adds a lot of extra code and complexity.

Comment 3

[Markus Stange [:mstange]]

(In reply to comment #2)
> Interesting, but it doesn't seem like something that should be used by default.

Why not? I've only been able to think of one example (<video> playback position) where the animation would adversely affect the user experience. I think all other normal progress bars would benefit from animation.

> I could see value in having a setValueSmooth type method perhaps, or a
> usesAnimation property as you suggest.
> 
> Is there a case where having smooth value adjustment is useful?

Maybe not useful, but surely beneficial - it just feels so much better (at least to me). There are many cases where animated transitions are much more natural than instantly jumping from one value to the next, and I think this is one of them.
It's also a question of platform nativeness. OS X progressbars animate their position by default, too.

> If not, it may
> be more worthwhile to wait until a decent animation api is available,

What kind of animation API do you have in mind? We already have an API for transitions and we can't use it here (because it doesn't provide a way of keeping the ongoing transition's velocity at the start of the new transition and because nsProgressmeterFrame sets the flex attribute and not the -moz-box-flex CSS property).

We can get rid of the timer management once we have a central refresh driver that sends "beforepaint" events.

> as the
> patch here adds a lot of extra code and complexity.

Yeah, we have to consider whether it's worth the complexity cost. In my opinion it is worth it.