Repository navigation
fix(web-animations-api): use bezier-easing 3.2 closed-form solver - #2256
Conversation
Replace the sample table + Newton-Raphson + bisection search with the closed-form solver of bezier-easing 3.2: exact (~1e-14 instead of up to ~1e-3), no backward jump on steep curves such as (1, 0, 0, 1). Progress outside [0, 1] now saturates to 0 / 1 instead of going through the old search, which returned arbitrary values there.
馃 Changeset detectedLatest commit: d38633b The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
@gre What impact might this bring? |
|
@gre Can we just switch to using the bezier-easing package directly? |
|
Hey @hustcc. It should only affects And yes, using the package directly makes sense. |
* perf(g): update animation promises once per frame (#2265) * perf(g): update animation promises once per frame Every animation started in a task queued its own no-op frame callback (AnimationTimeline.tick, and restart() when seeking), and the timeline wrapped each frame callback in two calls to updateAnimationsPromises, which goes over every animation with promises. Starting N animations in one task (G6 does this on every animated draw) therefore cost about 2路N虏 updatePromises calls in the next frame: 32 million for N = 4000. Run updateAnimationsPromises once before and once after the frame's callbacks instead. Nothing can change promise state between two callbacks of the same frame, so the extra calls did nothing. Tests: six traces of when ready/finished settle relative to frames and playState, recorded on 6.3.1 and unchanged; three tests that the bookkeeping stays linear when starting, or seeking paused or finished, animations in one task (6.3.1: ~2 million calls for n = 1000). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(g): assert the finished read in the promise scaling tests The helper read `animation.finished` only for its side effect (it puts the animation on the timeline's promise list), which CodeQL reports as an expression with no effect. Assert on it instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> * fix(web-animations-api): use bezier-easing 3.2 closed-form solver (#2256) Replace the sample table + Newton-Raphson + bisection search with the closed-form solver of bezier-easing 3.2: exact (~1e-14 instead of up to ~1e-3), no backward jump on steep curves such as (1, 0, 0, 1). Progress outside [0, 1] now saturates to 0 / 1 instead of going through the old search, which returned arbitrary values there. Co-authored-by: hustcc <i@hust.cc> * chore(release): bump version (#2268) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --------- Co-authored-by: Ethan-Icet <80927118+Ethan-Icet@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: @greweb <renaudeau.gaetan@gmail.com> Co-authored-by: hustcc <i@hust.cc> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Hi, this is @gre, I'm the author of bezier-easing, which is also embedded in this project (
packages/g/src/plugins/web-animations-api/utils/bezier-easing.ts). The library was recently improved with better performance and more reliability, and I wanted to backport the benefits here.This brings its 3.2 solver (closed-form, no sample table) to
cubic-bezier(...)easings:cubic-bezier(1, 0, 0, 1), 0.4996 returned 0.348 instead of 0.431, and the animation went backwards around the middle.Includes a patch changeset for
@antv/g. Thecustom-easingandanimation.timelineunit tests pass, and eslint and prettier are clean. Compared against bezier-easing 3.2 on ~7.6M values: bit-identical.