feat(dashboards): Use Motion design tokens for animation #102415
Conversation
github-actions
bot
added
the
Scope: Frontend
`x` and `y` coordinates are animated using `requestAnimationFrame`
This makes it possible to use them in Framer Motion components, which need numeric values.
More better performance!
gggritso
force-pushed
the
georgegritsouk/dain-1051-widget-builder-animation-is-janky
branch
from
180cdac to
524c51a
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| type: 'tween', | ||
| ease: theme.motionControlPoints.enter, |
There was a problem hiding this comment.
Kind of a bummer we went from physics controller moment to a fixed linear bezier motion curve. Will have to play with it, but my experience with simple bezier curves is that it's hard to get it to feel nice
There was a problem hiding this comment.
🤷🏻♂️ you tell me, I'm opting to use the motion tokens that we have. If that's not appropriate for panels I'm totally fine to move it back, as long as they can run at high FPS in busy situations
gggritso
changed the title
| motion: generateMotion(), | ||
| motionControlPoints: BEZIER_CONTROL_POINTS, | ||
| motionDurations: MOTION_DURATIONS, |
There was a problem hiding this comment.
could these be merged into theme.motion ? Could be a follow-up but I don’t think we should have too many top-level things on the theme, makes it harder to discover imo. Same as we have all tokens now grouped in theme.tokens
…02427) Peeled from #102415. Changes the Widget Builder (and Slideout Panel) animations to use `transform`. This forces Framer Motion to use GPU-accelerated animations rather than `requestAnimationFrame`. This noticeably improves performance when the main thread is busy (e.g., in the Widget Builder, all the time) and reduces jitter.
…02427) Peeled from #102415. Changes the Widget Builder (and Slideout Panel) animations to use `transform`. This forces Framer Motion to use GPU-accelerated animations rather than `requestAnimationFrame`. This noticeably improves performance when the main thread is busy (e.g., in the Widget Builder, all the time) and reduces jitter.
|
This PR's muddied the waters somewhat, I'm going to close it an open up something more sensible. |
…02427) Peeled from #102415. Changes the Widget Builder (and Slideout Panel) animations to use `transform`. This forces Framer Motion to use GPU-accelerated animations rather than `requestAnimationFrame`. This noticeably improves performance when the main thread is busy (e.g., in the Widget Builder, all the time) and reduces jitter.
EDIT: I removed some unrelated changes!
Change 1: Usingtransformfor animations. According to my profiling, animatingx,y, andopacitytogether in Framer Motion usesrequestAnimationFrame! When the main thread is busy (which is very often with the Widget Builder), this causes jittery animations. Yuck. Instead, I'm transitioningtransformdirectly, as per the Framer documentation. This delegates the transition straight to the compositor, which is way better! I applied this change to both the Widget Builder and the whole slideout panel.Using the motion Design Tokens. Scraps specifies the correct bezier curves and durations that we should use. I added some theme configuration that allows using the tokens in a Framer Motion context, by exporting the raw values. Then I dropped them in.
motion.snap.slowis way too fast for large panels, like the Widget Builder. Can we get another token, or should I use a custom value?