GSAP / Scrollmagic speed optimizations

[Battleaxe19]

Hey all,

I've been using Greensock and Scrollmagic to create a rather complex set of animations. Here is a link to the current demo: https://confident-sinoussi-6364a8.netlify.com/

My issue is that the animation feels rather choppy, and with mouse wheels that are clicky, it's super jumpy. ALSO, in Safari, after every new scene slides up into view, the old one flashes for a second right behind it.

 

The way im doing these animations is by adding every scene to an html file as individual inline svgs. Then I use greensock to create the tweens for each individual scene like this:

function scene1() {
  /***********************/
  /* Scene 1 (Cavemen) */
  /***********************/

  //Scene 1 parts (Cavemen)
  var s1Title = select('#Title_Card_1'),
  s1 = select('.scene1'),
  s1TitleSlide = select('#Title_Card_Slide_1'),
  s1ArmStart = select('#s1_Girl_Arm_Start'),
  s1ArmMiddle = select('#s1_Girl_Arm_Middle'),
  s1ArmEnd = select('#s1_Girl_Arm_End'),
  s1Fish = select('#s1_Fish'),
  s1ManArmStart = select('#s1_Man_Arm_Start'),
  s1ManArmEnd = select('#s1_Man_Arm_End'),
  s1LeashStart = select('#s1_Leash_Start'),
  s1LeashEnd = select('#s1_Leash_End')

  var tl1Main = new TimelineMax({paused:false});
  var tl1Animations = new TimelineMax({paused:true});

  tl1Main
  .fromTo(s1, 1, {y:1000}, {y:0})
  .fromTo(s1Title, 0.5, {autoAlpha:0}, {autoAlpha:1, onComplete: function() {
    tl1Animations.play();
  }, onReverseComplete:function(){
    tl1Animations.reverse();
  }})
  .from(s1TitleSlide, 1, {x:-460, ease:Linear.easeNone})

  tl1Animations
  .to(s1ArmStart, 0.5, {morphSVG:s1ArmMiddle, ease:Linear.easeNone}, 0.3)
  .to(s1Fish, 0.5, {x:30, y:20, ease: Linear.easeNone}, 0.3)

  .to(s1ManArmStart, 0.5,{morphSVG:s1ManArmEnd, ease: Linear.easeNone}, 0.3)
  .to(s1LeashStart, 0.5,{morphSVG:s1LeashEnd, ease: Linear.easeNone}, 0.3)

  .to(s1ArmStart, 0.4, {morphSVG:s1ArmEnd, ease:Linear.easeNone}, 0.8)
  .to(s1Fish, 0.4, {x:32, y:36, ease:Linear.easeNone}, 0.8)

  return tl1Main;
}

 

Each scene has a seperate set of animation that trigger when a user scrolls to a new scene, and a set of animations that are linked to the scroll with Scrollmagic.

All of these scene functions are then added to a master timeline like this:

var masterTimeline = new TimelineMax();

masterTimeline
.add(sceneIntro())
.add(scene1(), '-=0.6')
.add(scene2())
.add(scene3())
.add(scene4())
.add(scene5())
.add(scene6())
.add(scene7())
.add(scene8())
.add(scene9())
.add(scene10())
.add(scene11())
.add(scene12())
.add(scene13())
.add(scene14())
.add(scene15())
.add(scene16());

var controller;

$(function() {
    controller = new ScrollMagic.Controller();

    var scene = new ScrollMagic.Scene({
          duration: '6000%'
        })
        .setPin('#scene-wrapper')
        .setTween(masterTimeline)
        .addTo(controller);
});

 

And that's how we get the animation you see in my demo. I know a bunch of heavy svg's are being animated at once and that's probably the major cause for slowdown. I've lightly explored a bunch of options like debounce, and possibly porting this over to canvas but none of these routes seem that feasible at the moment. Any information or insight on how I can improve this product would be HUGELY appreciated.

 

Thanks dudes!

[GreenSock]

Yeah, sorry, it's really tough to troubleshoot a live site like that and try to wrap our heads around everything that's going on and then provide solutions for optimizing everything, but it certainly looks like a BIG issue is just that you've got a lot of SVG elements animating simultaneously that require repainting/compositing of large quantities of pixels. It's just a ton of work for the browser to do, unrelated to GSAP. 

 

I wish I had a silver bullet for you. 

 

If you have any GSAP-specific questions for us, we'd be happy to help. 

[Battleaxe19]

I understand that there's no way to diagnose that entire animation with what you've been given, but thanks anyways for the reply! That helps me, as it confirms that the large number of moving parts are what are most likely slowing things down. 

 

A few questions for you in that regard:

What are the most intensive animations? I've read that opacity/autoalpha is kind of resource intensive andf i'm changing that alot. Also, all of those title card things that slide out are filled with paths for each letter rather than an actual font. Would the sheer number of paths being animated affect speed? Are big complex svg's going to slow things down a noticeable amount by just being there, or is it more just animating a ton of svg paths at once? 

 

Again, any info at all is helpful, even if it's just general info. 

 

Thanks so much!

[mikel]

Hi @Battleaxe19

 

Welcome to the GreenSock Forum.

 

Just a guess, a suggestion (I'm not an expert on ScrollMagic):

It's a damn long scene 6000% and quite a few elements triggered by scroll!
How about building the individual scenes as separate 'parallaxContainers' (more here)?

I would animate the title cards independently; the focus - my taste - should be on the scene and its animations.

 

I wish you good luck and a perfect evolution ...

Mikel

 

 

[Battleaxe19]

Hey @mikel!

 

Thank you so much for the awesome suggestion. I went through a bunch of iterations before I landed on just adding everything to a single master timeline, and then scrolling through the whole thing. I think I am going to try your approach, and it shouldn't be too difficult for me to port what I have, as every scene is already separate.

 

I'll probably report back here once i've tried more stuff. 

 

Thanks all!

[GreenSock]

1 hour ago, Battleaxe19 said:

What are the most intensive animations? I've read that opacity/autoalpha is kind of resource intensive andf i'm changing that alot. Also, all of those title card things that slide out are filled with paths for each letter rather than an actual font. Would the sheer number of paths being animated affect speed? Are big complex svg's going to slow things down a noticeable amount by just being there, or is it more just animating a ton of svg paths at once? 

 

Nah, opacity usually isn't bad at all. Fonts might be slightly less CPU-intensive, but probably not much - they're still basically vectors. One of the biggest drains is just the sheer number of pixels that must be updated. So if you have exactly the same complexity in shapes, but they're shrunk down quite a bit, that's easier for the browser. And yeah, if an SVG is just sitting there doing nothing, it's not nearly as difficult for the browser - it basically has to ask the question "which pixels have changed" 60 times per second, and then repaint those. So if they don't change tick-to-tick, it's pretty easy-peasy. 

 

Good luck!

[mikel]

Hi @Battleaxe19,

 

To cheer up a small scene.
Even if you are not in Arizona ...

 

See the Pen VNxpPB by mikeK (@mikeK) on CodePen

 

 

I'm looking forward to the solution.

Mikel