progressCircular: spinner is too slow relative to spec

[naomiblack]

feedback from the core design team -- ProgressCircular is about 3x too slow.

have shared a better example with @ThomasBurleson. Can we get this updated?

See https://material.angularjs.org/latest/demo/progressCircular

[ThomasBurleson]

@clshortfuse - see attached SVG/HTML samples for speed, etc.

export.zip

This is for comparison only... not for re-implementation of the ngM1 spinners.

[crisbeto]

FYI the animation can be tweaked from here https://github.com/angular/material/blob/master/src/components/progressCircular/js/progressCircularProvider.js#L49

[clshortfuse]

It seems that the current implementation is incomplete. Just accelerating the animation might not be enough.

I see the animation having two cycles that I call extend and contract. The extend cycle pushes the "head" clockwise and extends at a faster rate. The contract cycle shortens the "tail" clockwise at a faster rate, making the ring small.

It seems our animation has the contract cycle right, but the extend cycle isn't extending the ring far enough. This is why is appears "slower" than spec.

[crisbeto]

Tweaking the animation so it accelerates in one phase should be pretty simple, we can either:

• Pass in a different duration - may end up causing overlapping animations.
• Pass in a different easing function that accelerates at a different rate.

We can pair up on this, if you need help @clshortfuse

[clshortfuse]

@crisbeto The problem is not the duration, but our current actual animation logic is too simplified. There are 4 pieces of logic that should be done in other to match spec 100%.

1. Increase the distance from ~0% to 75% using an ease-in function.
2. Decrease the distance from 75% to ~0% from the opposite end, using an then ease-out function
3. Rotate the object 90 degrees clockwise and start again.

** Repeat 3 more times (for a total of 4 iterations), optionally changing color each iteration **

1. We need to do all this, all the while the entire object rotates counter-clockwise 360 degrees each of 4 iterations.

(My use of ~0% means it can't be as close to 0% without actually being 0)

I've done all this already with pure CSS. The only issue is requestAnimationFrame has to be used for compatibility with IE, but luckily we are already using this in our current implementation. I'm not 100% sure about the easing function though. Also, RAF is smoother than keyframe approximations. The benefits are that we don't really need to do much intensive trigonometric math or rewrite the SVG path. We just need to make sure we ease the animation properly.

http://codepen.io/shortfuse/pen/jVNqyV?editors=1100

[crisbeto]

What I'm trying to say is that it's not complicated to pass in a different easing function, depending on the state of the animation.