Fluid, material design animations without lag

[adalinesimonian]

I went ahead and improved the indeterminate animation to better simulate the official animations from the Material Design spec. I've put in my best effort to ensure that doing this wouldn't cause any jank, and have gone through many different revisions before I settled on this one.

I've also put some good faith effort into making sure that existing styling wouldn't be affected, so I made sure the styles stayed dependent on the CSS variables that were already in paper-progress.

[blasten]

@vsimonian thanks for your contribution and the catch! I wonder if we could update the keyframes of #activeProgress so we wouldn't need an extra div.

[adalinesimonian]

@blasten I was hoping to do just that at first! The less tags, the better. I tried that out at first, and I was working on it for quite a while. As I went along, though, I encountered some significant hurdles trying to use only one element. The first thing that stood out was that no matter what curves I tried, the results were very mechanical compared to the Material Design examples (similar to how it is now, but different in its own ways). Eventually, as I was going through a number of revisions, I noticed that, in the design spec's examples, there is a point in the animation where two bars are visible at the same time (see below).

Another thing that seemed to be the biggest differentiating factor between the smooth animations in the spec and the jagged one in the element was that the left and right ends of both bars in the animation were asynchronously animated. Now, this could somewhat be done by individually animating the left and right CSS properties, but that would be a big sacrifice in smoothness and performance. Plus, I couldn't set different animation-timing-functions for different properties, which was a big bummer.

Taking that into account, in my next attempt I ended up trying to animate two bars by taking advantage of being able to constrain the child div to a parent, but I found this to cause lag spikes, even on a graphics-accelerated system (with an i7, no less!). I almost lost hope at this point! It was roughly 8 or so hours of work by then and it looked like it was hopeless trying to get it to be spec-compliant.

But then I came along with the idea of making it look like there were two bars streaming from left to right without having to actually move two elements from left to right, while still keeping the asynchronicity of the animation from the spec. That's the solution I ultimately ended up posting up here. By moving the second element, #indeterminateSplitter across #activeProgress, I was able to "mask" #activeProgress and make it look like it was, in fact, two bars, each with differently animated left and right ends, without having to employ animating anything but the transform property, and without even having to move #activeProgress all the way from-100%to100%`. This ended up having the cleanest effect I could muster, and had (at least in my testing) as little frame lag as the original animation. Put in another couple hours of fine-tuning the keyframes and curves... and voila!

I really would have preferred to use as little as possible, but the smallest number of elements I was able to use to achieve this effect was two, including #activeProgress. :pensive: Not saying that it is impossible! But I can certainly assure you that I put in my best efforts to try and make it happen. Now, that being said, if someone can hop along and make it work with some CSS wizardry, that'd be really sweet! I'm all for it. :smile:

[blasten]

@vsimonian thanks for the explanation & sorry for the late response. cc @frankiefu any thoughts?

[blasten]

Merged! Thanks!