+++ This bug was initially created as a clone of Bug #994954 +++ The previous spinner has an animation that can be supported by OMTA bug 788522 (!= OMTAImages bug 994954). In a few releases desktop will ship with OMTC support and not long after OMTA. Once that happens we can make the previous spinner very smooth. Bug 994954 landed a new spinner. This spinner is not compatible with OMTA and thus would require waiting for OMTAImages bug 994954 which is further out delaying the performance win to the user. I'm recommending that we keep the previous spinner so that we can make it smooth once OMTC+OMTA is ready (high on the list) and switch to the new spinner once OMTAImages is ready to make that smooth (later). Marking as blocking so that we avoid shipping a spinner and reverting it shortly after.

I guess it's a question of what we want sooner - guaranteed smoothness of the throbber animation, or the new throbber design. If we stick with the new throbber, we're waiting for an undefined amount of time for OMTA for images, so we're waiting for an undefined amount of time to get guaranteed smoothness of the throbber. If we revert to the old throbber, we're waiting several months for OMTA to be enabled, and then swapping over to using a static image with CSS transitions for guaranteed smoothness. Basically, it's your classic trade-off. What do we want?

(In reply to Mike Conley (:mconley) from comment #1) > I guess it's a question of what we want sooner - guaranteed smoothness of > the throbber animation, or the new throbber design. > > If we stick with the new throbber, we're waiting for an undefined amount of > time for OMTA for images, so we're waiting for an undefined amount of time > to get guaranteed smoothness of the throbber. > > If we revert to the old throbber, we're waiting several months for OMTA to > be enabled, and then swapping over to using a static image with CSS > transitions for guaranteed smoothness. > > Basically, it's your classic trade-off. What do we want? We could also still update the spinner APNGs with a version that can use a transform. e.g. this http://people.mozilla.org/~shorlander/mockups-interactive/australis-spinner-updates-i02/images/connecting-01.png and http://people.mozilla.org/~shorlander/mockups-interactive/australis-spinner-updates-i01/images/loading-05.png Or some variations of those.

We could use the second one, yes. Not the first link - the inner circle isn't rotating at the same rate as the outer.

(In reply to Mike Conley (:mconley) from comment #3) > We could use the second one, yes. Not the first link - the inner circle > isn't rotating at the same rate as the outer. We couldn't animate two nested elements separately?

(In reply to Stephen Horlander [:shorlander] from comment #4) > (In reply to Mike Conley (:mconley) from comment #3) > > We could use the second one, yes. Not the first link - the inner circle > > isn't rotating at the same rate as the outer. > > We couldn't animate two nested elements separately? I suppose we could, yes. That increases the complexity of the CSS, but do-able in theory. I stand corrected. :)

We could, and that's it totally fine by me. The overall cost will be virtually identical (except more image decoding so some startup delay).

I find the nested circles moving differently jarring, but in any case, I don't think we should go out of our way and nest elements with multiple images and multiple CSS animations. Let's please use a simpler design like we and pretty much any other software has been using since the beginning of time, and possibly switch to something more fancy when APNGs are animated off the main thread.

I'd also like to see what the rotationally-transformed throbber looks like. It can be a subtle difference, but a lot of web throbbers do this, and it looks bad. Instead of appearing as a line following a circular track it, it literally looks like a crudely rotating image. This is most obvious in cases where the image isn't even centered, and so rotates like an off-centered wheel.

(In reply to Mike Conley (:mconley) from comment #1) > I guess it's a question of what we want sooner - guaranteed smoothness of > the throbber animation, or the new throbber design. > > If we stick with the new throbber, we're waiting for an undefined amount of > time for OMTA for images, so we're waiting for an undefined amount of time > to get guaranteed smoothness of the throbber. > > If we revert to the old throbber, we're waiting several months for OMTA to > be enabled, and then swapping over to using a static image with CSS > transitions for guaranteed smoothness. > > Basically, it's your classic trade-off. What do we want? Given that the new throbbers also seem to cause some other fallout (bug 1008581), sticking with the old ones until we have OMTA is what we should do. Once that happens, we can do some other experimentation to improve the (perceived) performance of the throbbers (like nonlinear animation). So let's back out the patch to bug 994954 for now.

Fixed by backout of bug 994954. Dependency on bug 717872 noted there.

(In reply to Benoit Girard (:BenWa) from comment #0) > The previous spinner has an animation that can be supported by OMTA bug > 788522 (!= OMTAImages bug 994954). In a few releases desktop will ship with > OMTC support and not long after OMTA. Once that happens we can make the > previous spinner very smooth. > > Bug 994954 landed a new spinner. This spinner is not compatible with OMTA > and thus would require waiting for OMTAImages bug 994954 which is further > out delaying the performance win to the user. I'm a bit confused by this, though. I thought both the previous and the "new" spinners were animated images? That's what the patch in bug 994954 suggests to me.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #11) > (In reply to Benoit Girard (:BenWa) from comment #0) > > The previous spinner has an animation that can be supported by OMTA bug > > 788522 (!= OMTAImages bug 994954). In a few releases desktop will ship with > > OMTC support and not long after OMTA. Once that happens we can make the > > previous spinner very smooth. > > > > Bug 994954 landed a new spinner. This spinner is not compatible with OMTA > > and thus would require waiting for OMTAImages bug 994954 which is further > > out delaying the performance win to the user. > > I'm a bit confused by this, though. I thought both the previous and the > "new" spinners were animated images? That's what the patch in bug 994954 > suggests to me. Yes, both were animated images, but we could achieve the same visual effect as with the old spinners by rotating a static image (which can be supported by OMTA). The new spinner uses a more complex animation that can't be easily achieved using CSS animations.

Oh, so the objection was to the design, not the particular implementation in bug 994954. I see.

Note that, as stated by Comment 4, we can have more complicated effects by having multiple synced animated CSS transform.