[Firefox Performance Issues]

Just wanted to know if anyone has any experience dealing with performance issues on Firefox. I've got a site that uses a lot of SVG animations and it works great on all other browsers, however Firefox performance is lacking to say the least. Is this a common issue with Firefox? Is there anything one can do to help boost performance? I read an older article here https://greensock.com/forums/topic/11337-firefox-performance/ which talks about FFs issues, but I would think (or at least hope) those issues would have been addressed after 2+ years. 

 

Any adivce would be much appreciated!

 

Thanks,

James

 

[Infinite looping nested timeline blocks main timeline]

20 hours ago, OSUblake said:

 

It's generally a good idea to keep infinite animations separate if you plan on reusing the timeline. 

 

And I would not use an anonymous function. When you reverse your timeline, it's going to call that function again, so your stairsIdle timeline will still be playing even if the element isn't visible. Inspect the element in your dev tools.

 

 

A better approach might be to add and remove a callback when necessary.

 

 

 

 

Thanks for the tips @OSUblake. I took a slightly different approach with a reverseScene function which cleans things up as I transition to the next page. The code for anyone interested: 

   // Main timeline
    const mainTL = new TimelineMax({ delay: 1 });

    mainTL
      .add(stairsTL.play(), 'stairs')
      .add('stairsCallback')
      .add(playStairsIdle, 'stairsCallback')
      .add(limoTL.play(), 'stairs+=0.25')
      .add('limoCallback')
      .add(playLimoIdle, 'limoCallback')
      .add(luggageTL.play(), 'stairs+=0.5')

    function playStairsIdle () {
      stairsIdle.play();
    }

    function playLimoIdle () {
      limoParticlesIdle.play();
      limoSparklesIdle.play();
      limoBounceIdle.play();
    }

    function reverseScene (cb) {
      // Repeat 1 allows staggered animation to play out while we're reversing
      limoParticlesIdle.repeat(1);
      limoSparklesIdle.repeat(1);
      limoBounceIdle.pause();

      mainTL
        .remove(playLimoIdle) // Ensures we don't play this on reverse
        .remove(playStairsIdle) // Ensures we don't play this on reverse
        .reverse()
        .timeScale(2)
        .eventCallback('onReverseComplete', () => {
          // Kill all looping animations
          stairsIdle.kill();
          limoParticlesIdle.kill();
          limoSparklesIdle.kill();
          limoBounceIdle.kill();

          if (cb && typeof cb === 'function') {
            cb();
          }
        });
    }

 

[Infinite looping nested timeline blocks main timeline]

8 minutes ago, Dipscom said:

Thanks.

 

Age must be getting to me. I went to the docs looking for it and did not spot the entry. Probably because it is siting right at the top of the list, not where I expected it to be, in alphabetical order. 

If it's any consolation, I did the same thing earlier. Took me a minute to find it up at the top (was expecting alphabetical).

[Infinite looping nested timeline blocks main timeline]

For those that may come across this, while the above works well, if you're adding an infinite looping timeline to a main timeline it will then cause the main timeline to grow in time, which makes sense. Unfortunately, if you want to reverse the animation (for say a transition out) it will play back the entire main timeline which means if the looping timeline has been playing for awhile then the main timeline will have a lot of time to playback on. My solution to have an idle infinite looping animation that doesn't effect the main timeline, but can still be called when desired on the main timeline was to use .call with an anonymous function.

 

mainTL
  .add(stairsTL.play(), 'stairs')
  .call(() => {
    stairsIdle.play();
  })
  .add(luggageTL.play(), '-=1')

 

[Infinite looping nested timeline blocks main timeline]

13 minutes ago, OSUblake said:

You need to find the end time of the last item.

mainTL
  .add(stairsTL.play(), 'stairs')
  .add("luggage", stairsTL.recent().endTime(false))
  .add(luggageTL.play(), 'luggage')

 

See the Pen qmxpdj?editors=0010 by osublake (@osublake) on CodePen

 

 

I see, so because stairsIdle is infinite there is no end time, so we add one (a time) via a label to continue the main timeline. Good trick to know. Thanks!

[Infinite looping nested timeline blocks main timeline]

I have had some luck replacing .add(stairsIdle.play(), 'stairsIdle') with .call(stairsIdle.play(), 'stairsIdle') but get a TypeError of Uncaught TypeError: callback.apply is not a function which is worrying.

[Infinite looping nested timeline blocks main timeline]

I've got a number of timelines which I want to control via a master timeline. This all works great, except for when one of those nested timelines is infinitely looping. It blocks the main timeline. I figure this must be because the time of the infinite timeline is, well... infinite, therefore the main timeline has no cue to continue, but how does one get past this?

See the Pen VbyNGq by getreworked (@getreworked) on CodePen

[Possible to Stagger Call?]

Hi Mikel, thanks for writing back. Cool Codepen I'm actually using GSAP to run timelines for effects that interact with node.js and the Phillips Hue light api, not any actual DOM animation. It could be total overkill using GSAP for this, but we'll be using GSAP for animations within the interface, so I figured why not. I've actually written a simple function to do what stagger does, but it calls functions instead. Here's the code for anyone interested in doing the same

/**
* Walk  - Use this to create a new effect instance
* eg. let pulseGrp1 = new pulse([1,2,3]);
* @param {Array} lights - An array of light IDs. eg. [1,2,3]
*/
walk (lights) {
  this.lights = lights;

  let timeline = new TimelineMax({ paused: true });
  let time = 0;
  let offset = 0.5;

  lights.forEach((el, index) => {
    timeline
      .call(this.lightsOn, [[el]], this, time)
      .call(this.lightsOff, [[el]], this, time + offset)

    time += offset;
  });

  return timeline;
}

[Possible to Stagger Call?]

Is it possible to stagger a call? I'm using GSAP quite unconventionally for a node project where we turn lights on / off to create effects. So far using the call function it's been quite easy to put together effect timelines. It'd be great if I could toss stagger in to the mix, but I don't think it's possible. Just thought I'd check before going about writing up something to handle a stagger like effect.

 

Thanks in advance!