Compile to css keyframes when possible
chenglou opened this issue · comments
How do you envision this working?
This is strictly an optimization detail a-la uploading instructions to the GPU. The API should not be affected by this.
You basically precompute the values and construct your css animation markup. In lots of cases we can use built-in CSS transitions (easeInOut, linear, etc.). But if a second animation on the same value comes along, you'd have to erase the first one and resort to using keyframes (since the addition of two animations won't be a built-in CSS interpolation). Of course, this problem doesn't exist for destructive animations, but I think additive animation is very useful, and the fact that additive animations can only be done in JS demonstrates the power of this lib. Or else we'd all go back to the underpowered CSS animations!
When I created this issue, I forgot that CSS keyframe animations were done in percentages, not frames (sigh...). This means you can't emulate a custom transition by writing out all the frames. Percentages work badly for transitions that last longer since the lapse between percents lasts longer. Also, juggling between CSS and CSS keyframes being percentages are fine since they allow two decimals and it's enough for our purposes. We can always create more keyframes declarations and chain them.requestAnimationFrame renders gives unpredictable render cycles. This is probably low-priority for now.
Too complicated.