The ease can work on timeline whole animation?

[df257666]

var tl = gsap.timeline({ defaults: {duration: 1, ease: "elastic"} } );

tl.to(".open", {duration:0.2, scaleX:-1});
tl.to(".open", {duration:0.2, scaleX:1});

tl.play();

this way will get pushed into every child tween, I don't want that.

 

I want this ease will work on this animation, not in every child tween;

My english not well, do you understand?

[OSUblake]

You can use keyframes if you're using the same target.

 

See the Pen 5a8c8feb233e5bcd66b87b40be8095ac by osublake (@osublake) on CodePen.

 

 

[df257666]

[mikel]

Hey @df257666,

 

Special ease for entire timeline - tween the timeline ...

 

Here an example

 

See the Pen RwNKBrB by mikeK (@mikeK) on CodePen.

 

Happy easing ...

Mikel

[df257666]

@mikel @OSUblake

I solved it，very thank to you!

 

[ZachSaucier]

You probably don't need the time property in the tween animating the tl. Also we recommend using the condensed form of eases, in this case ease: 'circ'.

[chrisgannon]

5 hours ago, OSUblake said:

You can use keyframes if you're using the same target.

I would love to be able to use keyframes with different targets. @GreenSock

[OSUblake]

6 hours ago, chrisgannon said:

I would love to be able to use keyframes with different targets. @GreenSock

 

What were you thinking for the api? I was thinking of something like this. Just a normal timeline, but treat it differently.

 

gsap.timeline({
  keyframes: true, // tell it to treat timeline as keyframes
  keyframesEase: "circ" // ease to use
})
.to(a, { ... })
.to(b, { ... });

 

[chrisgannon]

19 minutes ago, OSUblake said:

 

What were you thinking for the api? I was thinking of something like this. Just a normal timeline, but treat it differently.

 

gsap.timeline({
  keyframes: true, // tell it to treat timeline as keyframes
  keyframesEase: "circ" // ease to use
})
.to(a, { ... })
.to(b, { ... });

 

 

My idea to just use it in the same way as it's already used:

gsap.timeline({
  defaults: {
      ease: 'circ'
  }
});

tl.to('#a, #b', {
  keyframes: [
    { ... },
    { ... }
  ]
})

I think both approaches have their upsides although I would be reluctant to add more special properties given the framework already has syntax to handle multiple targets.

 

I do like the fact your suggestion supports from and fromTo though

[GreenSock]

7 hours ago, chrisgannon said:

I would love to be able to use keyframes with different targets. @GreenSock

I'm struggling to understand what you mean here. Can you provide an example (pseudo code)? 

 

20 minutes ago, OSUblake said:

 

What were you thinking for the api? I was thinking of something like this. Just a normal timeline, but treat it differently.

 

gsap.timeline({
  keyframes: true, // tell it to treat timeline as keyframes
  keyframesEase: "circ" // ease to use
})
.to(a, { ... })
.to(b, { ... });

 

Again, I'm probably missing something obvious but why do we need any of this? Doesn't the current API already make this possible? For example, here's a helper function that'd let you pass in an Array of keyframe objects: 

function keyframes(data, {defaults, ease}) {
  let tl = gsap.timeline({paused: true, defaults: defaults}),
      targets, tweenVars, p;
  data.forEach(keyframe => {
    targets = keyframe.targets || targets;
    tweenVars = {};
    for (p in keyframe) {
      p !== "targets" && (tweenVars[p] = keyframe[p]);
    }
    tweenVars.ease = keyframe.ease || "none";
    console.log("ease:", tweenVars.ease, tweenVars);
    tl.to(targets, tweenVars);
  });
  return gsap.to(tl, {progress: 1, ease: ease || "none", duration: tl.duration()});
}

// USAGE: 
keyframes([
  {targets: ".box", y: 100},
  {targets: ".box-1, .box-2", x: 100},
  {targets: ".box-3", rotation: 360}
], {
  ease: "power3", // <-- ease applies to the whole timeline
  defaults: {duration: 2}
});

You can skip defining "targets" in subsequent keyframes and it'll just use the same one as the previous keyframe. And you could define an ease for any individual keyframe. It's the same thing as a "vars" object for a typical tween, but it also has a "targets" property. 

 

Does that help at all? 

 

I guess I'm struggling to see the value of all this, especially since the existing API is easy to string things together like .to(...).to(...) with multiple targets. In other words, how is that any different than this keyframe stuff (other than a tiny bit of extra code that makes the default ease "none", wraps things in a timeline and animates the progress)? 

[GreenSock]

16 minutes ago, chrisgannon said:

 

My idea to just use it in the same way as it's already used:

gsap.timeline({
  defaults: {
      ease: 'circ'
  }
});

tl.to('#a, #b', {
  keyframes: [
    { ... },
    { ... }
  ]
})

 

Are you saying that code doesn't work currently? I just tried it and it seems to work okay, so I must be missing something. 

[OSUblake]

1 hour ago, GreenSock said:

I guess I'm struggling to see the value of all this, especially since the existing API is easy to string things together like .to(...).to(...) with multiple targets. In other words, how is that any different than this keyframe stuff (other than a tiny bit of extra code that makes the default ease "none", wraps things in a timeline and animates the progress)? 

 

The point is just to simplify a somewhat common technique.

 

[GreenSock]

3 minutes ago, OSUblake said:

The point is just to simplify a somewhat common technique.

I see. I think it'd help if I saw more pseudo code - like a comparison between what it is now and what it would look like in the "improved" version. 

 

In the example you provided, @OSUblake, is the only difference that setting keyframes: true would force all of the child tweens to use an ease of "none" (identical to defaults: {ease: "none"}) AND the virtual playhead would move in a non-standard way that wouldn't conform to the current logic? In other words, if you set keyframesEase: "power3" on a timeline that has 4 one-second sequenced tweens (keyframes), and then you move the playhead to 2 seconds (halfway through, progress: 0.5), the child tweens would get rendered as if the playhead was at a time of 3.75 (progress: 0.9375)?

 

If so, that could be rather problematic because suddenly a timeline's virtual playhead no longer corresponds to its position on its parent timeline, etc. It rips a hole in the time-space continuum

 

Does the helper function I provided already address the desire to simplify things (without introducing the inconsistencies I mention above)? I'm not opposed to simplifying things for sure. In all my years doing this I haven't heard much of a complaint about the current API not making it easy enough to animate multiple things or create keyframe-like animations, but then again my memory is getting worse as I get older. And sometimes even though people haven't expressed a need for something, if we deliver it they may say "how did I ever live without this!" So again, I'm open to improvements, but I want to be very careful about not inadvertently introducing logic inconsistencies or bloating the file size for the sake of a very few people who'd use it (not saying only a few people would...I'm just saying that IF only a few people would, I don't like adding kb for something that's already totally doable with the current API). 

[OSUblake]

12 minutes ago, GreenSock said:

AND the virtual playhead would move in a non-standard way that wouldn't conform to the current logic? In other words, if you set keyframesEase: "power3" on a timeline that has 4 one-second sequenced tweens (keyframes), and then you move the playhead to 2 seconds (halfway through, progress: 0.5), the child tweens would get rendered as if the playhead was at a time of 3.75 (progress: 0.9375)?

 

I'm not sure I understand the logic of that. Can you explain?

 

Your function is fine, but it's not built in. I guess the overall thing I'm suggesting here is to be able to apply an ease to a timeline.

 

 

[GreenSock]

27 minutes ago, OSUblake said:

I'm not sure I understand the logic of that. Can you explain?

All rendering is based on where the playhead is. There's various logic internally (and probably other people run external logic based on this too) that's based on this, like for example:

function globalTime(animation, rawTime) {
  let time = rawTime || rawTime === 0 ? rawTime : animation.rawTime();
  while (animation) {
    time = animation.startTime() + time / (animation.timeScale() || 1);
    animation = animation.parent;
  }
  return time;
}

That won't work if we decouple a timeline's playhead from its actual time. 

 

Of course I could introduce a new "ratio" value that serves this purpose sorta like it does in tweens, so I'm not saying it's impossible but it's definitely not a simple tweak. And if anyone else has logic baked into their code that assumes the playhead actually reflects the "time", it'd break that too. See what I mean? 

[GreenSock]

Maybe this is a simpler way of explaining it...

 

Let's say I've got a timeline that happens to have your suggested "keyframes: true" set. It's 10-seconds long. Then later, I do this: 

tl.add(otherTween, 5); // inserting it at exactly 5-seconds (halfway in)

And then I do this:

tl.time(5); // where's the playhead? At 5-seconds? What if the timeline has an ease applied?

Would that start playing at the very start of otherTween? What if the timeline has a keyframesEase of "power3"? Would setting the time() to 5 actually make the playhead act like it's at 9.375? If so, isn't that kinda weird? 

[df257666]

14 hours ago, ZachSaucier said:

You probably don't need the time property in the tween animating the tl. Also we recommend using the condensed form of eases, in this case ease: 'circ'.

In my case, if probably don't need the time property in the tween animating, the animation didn't meet my requirements.

this is my case>>