Jump to content
GreenSock

Fakebook

Performance and Visual Optimizations

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I'm getting towards the end of a project, and started wondering about performance and improving the overall quality of the animations I'm making.

 

In the example pen, I have a few questions.

 

1. Does using x, y improve the animations over using top, bottom, left, right?

In a video by Paul Irish it looks like using translate for CSS animations is performs better, especially in more complicated examples, is this similar with GSAP? Looking at the GSAP tests, this seems different, though. I'm not sure if my eyes deceive me, but I do see a bit of a "staircase" effect on the letters.

 

2. How would you use x and y translates with staggerFrom + letters wrapped in spans?

I'm not sure I understand using x and y properly - when I add to the spans of the letters in the example, it doesn't work.

 

3. Will lowering the ticker's call time help with performance?

While Tweens may not be as smooth, will the browser use less resources if set to something like:

 

 TweenLite.ticker.fps(30); 

 

See the Pen dmzBBz by NerdOrDie (@NerdOrDie) on CodePen

Link to comment
Share on other sites

1. Ya x and y translates work better than left and top. When you animate left or top property it causes layout recalculation. x and y translate take advantage of GPU and doesn't cause layout trigger so they perform better.

 

2. Span tags are inline by default and css transforms don't work on inline elements, if you set your span tag's display as inline-block then it will work.

 

3. Ya game developers use that trick but if you visit some of the websites from examples page, you will rarely find someone doing that. Generally if your animation isn't performing at 60fps on PC or on even some high end mobiles then you are doing something wrong or asking browser to do too much work. 

 

https://csstriggers.com/

 

You can optimize performance by avoiding triggers wherever possible. Avoid animating too many elements and use canvas to animate.  Avoid creating too many tweens on movemove, scroll events by using requestAnimationFrame, so your calculations will happen only once per frame. Start measuring performance of your work from start, on mobile and by using chrome's CPU throttling. So you will have idea about how much more you can do on the page and keep performance better. Also about setting animation to 30FPS, if your animation drops around 30-45FPS on PC it will drop below 30 on mobiles, so optimizing has to be your first step.

 

You can search through the forum for discussions on performance, recently we are getting a lot of questions on performance.

  • Like 3
Link to comment
Share on other sites

Thanks, @Sahil - not sure how I missed the display: inline-block property, but that seems to do the trick.

 

When taking advantage of translate via x and y, I noticed a similar issue to what I posted in this thread. I went ahead and applied a similar fix which was recommended there. In this test, things don't look too different, but it's good to hear in more complicated animations there are definite advantages.

 

force3D: false

 

Also, I think creating in canvas is what I'm going to be looking at very soon. It seems that GSAP + PixiJS is the obvious choice for performant tweening. Are there any other recommendations on GSAP + canvas? 

 

Updated pen: 

 

See the Pen geGONz by NerdOrDie (@NerdOrDie) on CodePen

 

Link to comment
Share on other sites

No I haven't heard of any other library than PixiJS, GSAP has plugin for it as well. It seems best option for 2d animations on canvas.

 

Forgot to point out, you see staircase effect because you are using Elastic ease.

  • Like 1
Link to comment
Share on other sites

Ah, thanks @Sahil - I'm a fan of that bounce effect since it goes past the preset y value compared to the bounce easing. Is there any solutions to smoothinig that out, or would it be best to use a fromTo and some other tweens to simulate the effect?

Link to comment
Share on other sites

You can play with custom ease to get desired effect when usual eases don't work for you.

 

You can also merge two eases by using this demo by @GreenSock if you are after an effect like that.

 

See the Pen aYLjjz?editors=0010 by Sahil89 (@Sahil89) on CodePen

 

  • Like 3
Link to comment
Share on other sites

Great, this looks perfect @Sahil - out of curiosity... do to tweens perform better than from tweens?

Link to comment
Share on other sites

While not a benchmark, you can look at the source code and see the difference. A from tween is the same thing, but it adds runBackwards and immediateRender to the vars.

 

TweenLite.to = function(target, duration, vars) {
  return new TweenLite(target, duration, vars);
};

TweenLite.from = function(target, duration, vars) {
  vars.runBackwards = true;
  vars.immediateRender = (vars.immediateRender != false);
  return new TweenLite(target, duration, vars);
};

 

  • Like 3
Link to comment
Share on other sites

  • 1 year later...
2 minutes ago, MrTwister said:

When animating DOM elements, adding will-change: transform to the most resource intensive ones can provide a significant performance boost.

This isn't always true. You should definitely read this article about will-change:

 

 

  • Like 1
Link to comment
Share on other sites

2 minutes ago, ZachSaucier said:

This isn't always true. You should definitely read this article about will-change:

 

 

Very interesting, thanks for the article!

But I'm currently working on a DOM animation with lot's of random tweens and it massively improved performance on Safari and Firefox.

Link to comment
Share on other sites

2 hours ago, MrTwister said:

When animating DOM elements, adding will-change: transform to the most resource intensive ones can provide a significant performance boost.

https://developer.mozilla.org/de/docs/Web/CSS/will-change

 

I would also recommend this advice. Most of the problems people have from will-change is that they might overuse it, when scaling something up, or because they don't understand stacking contexts/layers.

 

I just posted something about stacking contexts/layers here.

 

 

 

Another good read about stacking contexts/layers.

https://dassur.ma/things/forcing-layers/

 

Quote

When you animate an element on a frame-by-frame basis using requestAnimationFrame(). It’s hard — nay, impossible for the browser to tell that the element will have a new value for transform each frame. Unless you put the animated element on its own layer yourself, you will run into performance issues because the browser will re-paint the entire document every frame.

 

GSAP uses requestAnimationFrame, and using will-change creates a new layer, so that's why it can really improve performance.

 

CSS animations typically don't run into this problem.

 

Quote

Whenever you use CSS Animations or CSS Transitions, the browser will automatically put the animated elements on a layer for you. It keeps the main canvas around for the next frame and keeps the additional work as low as possible.

 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×