Bug 45761

I think we should add some new timing functions at the same time. When people want a cubic to extend beyond [0,1] they are most likely doing some kind of bounce effect. It would be much more author friendly to have timing-function: bounce-in, maybe with a parameter that says the number of bounces.

I think we should add more timing functions, but as a later step. We should survey the JS libraries to get a feel for what interesting functions are.

Created attachment 107476 [details] Patch

Comment on attachment 107476 [details] Patch With this change, isn't it possible to now exceed the start/end range for an animating value? How is that handled?

(In reply to comment #4) > (From update of attachment 107476 [details]) > With this change, isn't it possible to now exceed the start/end range for an animating value? How is that handled? Judging by how other browsers handle it, it only exceeds the range when the exceeding values make sense. For example, animating from a color to an edge RGB color like blue or fuchsia won't produce any bounce, because values above 255 are invalid.

(In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 107476 [details] [details]) > > With this change, isn't it possible to now exceed the start/end range for an animating value? How is that handled? > > Judging by how other browsers handle it, it only exceeds the range when the exceeding values make sense. For example, animating from a color to an edge RGB color like blue or fuchsia won't produce any bounce, because values above 255 are invalid. Correct. An animation from #555 to #CCC which bounces might touch #DDD (or even #FFF if the bounce is big enough), but will be clamped thereafter. As expected, white will remain white and black will remain black; the same applies to other colors. Transforms (e.g. rotating ones) overshoot slightly prior to moving back. One exception here are shadows, as they cannot transition between normal and inset ones (thus cannot bounce as such either) yet.

Comment on attachment 107476 [details] Patch Could you add a test that makes sure values are clamped? ie. animate colors. Unfortunately our hacky test-helping library doesn't really support colors that well. I added something like it in the test for transitions on SVG properties. Also, it's not clear what effect this will have on hardware animations using Core Animation. I'll have to check. r- just because I think we have to exercise the clamping now that it is possible to produce values outside the normal bounds.

ping?

I'll post an updated patch tomorrow, apologies for the delay.

Created attachment 109026 [details] Patch Updated patch. This adds tests for SVG Lengths, colors, shadows and transforms.

I filed https://bugs.webkit.org/show_bug.cgi?id=69032 to make sure the Safari CoreAnimation ports still work after this change.

Comment on attachment 109026 [details] Patch Clearing flags on attachment: 109026 Committed r96276: <http://trac.webkit.org/changeset/96276>

All reviewed patches have been landed. Closing bug.

My fault, but we should still clamp the X coordinate values.