2.x updateTo in 3.x ?

[CryOfGaming 1 Likes (Newbie)]

Hello,

 

i wanted to upgrade from the old 2.x to the latest 3.x GSAP. Mostly everything is working, except the code below.

I need to update variables during the animation without changing or resetting the duration—it should just continue to the new path like nothing happened. 

 

In 2.x it was working perfectly, now im messing around with "quickTo()", "invalidate()", trying to get the old "duration()" and inserting it in the updated tween, but nothing works like in 2.x.

 

Could someone suggest me how to achieve the same 2.x updateTo() effect without resetting the duration?
It's also important to be as efficient as possible. Lots of objects get created, each having this update function which get called many times per second in each individual object.

 

Thank you!

 

this.Tween.updateTo({
  x: newPositionX, 
  y: newPositionY
}, false); //false = Dont reset duration!

[GreenSock 18,578 Likes (Superhero)]

There isn't a direct equivalent in 3.x because that method was something that almost nobody used and it just didn't seem worthwhile kb-wise to have in 3.x. But you should totally be able to recreate that functionality. Just so I'm clear, are you saying that many times per second you're updating a destination value and you want to keep the overall duration the same but basically redirect where the values are going? So, for example, if x is animating from 0 -> 100 linearly over the course of 1 second and then at 0.9 seconds you want to change the destination to 500, it would then travel from 90 to 500 over the course of 0.1 seconds (super fast)? 

 

// chop the duration to whatever time is left, and then invalidate so it flushes out the recorded start/end values
tween.duration(tween.duration() - tween.time()).invalidate();
// then update the destination values on the vars object.
tween.vars.x = newPositionX; 
tween.vars.y = newPositionY;
tween.restart();

Does that work for you? 

 

The main thing that doesn't do (which updateTo() did) is adjust for the easing. If you need that, there's probably a more complicated way to work around that. Just let us know if that's a requirement.

[GreenSock 18,578 Likes (Superhero)]

If you need easing factored in, here's an "unofficial" helper function: 

function redirect(tween, vars) {
	let inv = 1 / (1 - tween.ratio);
	for (let p in vars) {
		tween.vars[p] = vars[p];
	}
	tween.invalidate().render(tween.time());
	let adjust = obj => {
		let pt = obj._pt, end;
		while (pt) {
			if (pt.d && pt.d._pt) { // plugin
				adjust(pt.d);
			} else {
				end = pt.s + pt.c;
				pt.c *= inv;
				pt.s = end - pt.c;
			}
			pt = pt._next;
		}
	};
	adjust(tween);
	return tween;
}

Usage: 

redirect(tween, {x: 1000, y: 500});

See the Pen oNMryZZ?editors=0010 by GreenSock (@GreenSock) on CodePen

 

That should pretty well replicate the old updateTo() method behavior that you were after.

[CryOfGaming 1 Likes (Newbie)]

1 hour ago, GreenSock said:

There isn't a direct equivalent in 3.x because that method was something that almost nobody used and it just didn't seem worthwhile kb-wise to have in 3.x. But you should totally be able to recreate that functionality. Just so I'm clear, are you saying that many times per second you're updating a destination value and you want to keep the overall duration the same but basically redirect where the values are going? So, for example, if x is animating from 0 -> 100 linearly over the course of 1 second and then at 0.9 seconds you want to change the destination to 500, it would then travel from 90 to 500 over the course of 0.1 seconds (super fast)? 

 

// chop the duration to whatever time is left, and then invalidate so it flushes out the recorded start/end values
tween.duration(tween.duration() - tween.time()).invalidate();
// then update the destination values on the vars object.
tween.vars.x = newPositionX; 
tween.vars.y = newPositionY;

Does that work for you? 

 

The main thing that doesn't do (which updateTo() did) is adjust for the easing. If you need that, there's probably a more complicated way to work around that. Just let us know if that's a requirement.

 

Thank you for your help! Unfortunatly it seems to not be the solution.

 

This is how it looks in 2.x with "updateTo" which is exactly what i want: 

See the Pen PoBrabR by cryofgaming (@cryofgaming) on CodePen

A nice, smooth update. And as you exactly said, it speeds up to reach the targetposition because it has less and less time available.

 

And this is the solution, you provided. It's not smooth and jumps around. 

See the Pen MWBMXeM by cryofgaming (@cryofgaming) on CodePen

 

I hope it's understandable what i try to achieve. 

[GreenSock 18,578 Likes (Superhero)]

I think you replied before I edited my answer (I was in a rush, sorry)

 

You just need to add tween.restart()

[CryOfGaming 1 Likes (Newbie)]

6 minutes ago, GreenSock said:

I think you replied before I edited my answer (I was in a rush, sorry)

 

You just need to add tween.restart()

Yes the restart fixed the problem. THAnk YOu

 

I need to have all performance possible, what do you suggest to use for the best performance?

Should i use the method you provided (which also works awesome) or the fixed answer with "tween.restart()"?

 

If we already talk here, does the "DynamicProps" Plugin exist for 3.x? If yes, where can i get it? And also, is the plugin performant?

Everything needs to run as performant as possible, even just a millsec. Slower can be a big problem 

[GreenSock 18,578 Likes (Superhero)]

11 minutes ago, CryOfGaming said:

I need to have all performance possible, what do you suggest to use for the best performance?

Should i use the method you provided (which also works awesome) or the fixed answer with "tween.restart()"?

 

You probably won't notice any real-world difference, but the first one is technically cheaper performance-wise because you don't have to loop through all the properties to adjust for the easing. Plus the 2nd version (helper function) is technically tapping into private properties that might change in a future update. So unless you really NEED the easing adjustment of that 2nd solution, I'd definitely stick with the first. 

 

If you're concerned about performance, you definitely shouldn't be changing top/left values frequently like in your demo. Just use transforms (x/y). In almost every case that I've seen, performance problems have nothing to do with the GSAP code and everything to do with graphics rendering performance in the browser. So make sure you're obsessing about the right things  

 

14 minutes ago, CryOfGaming said:

If we already talk here, does the "DynamicProps" Plugin exist for 3.x? If yes, where can i get it? And also, is the plugin performant?

No, but pretty much anything is possible to do with the current platform. I think it'd be much better for you to explain what you're trying to do from more of a macro level because sometimes I see people getting super caught up in the minutia of a very particular technical issue but their overall approach from an engineering standpoint needs an overhaul and if they did that, it'd greatly simplify or eliminate a lot of their challenges. 

 

Why do you feel the need to use DynamicPropsPlugin? Are your values constantly changing? Why? There may be an entirely different approach that'd end up being more performant and there'd be no need whatsoever for a DynamicPropsPlugin. 

 

If you can provide a super clear minimal demo illustrating the challenge you're facing, that'd be helpful. Just the most basic thing you can think of (a few colored <div> elements) is fine. Your earlier demos were great. 

[CryOfGaming 1 Likes (Newbie)]

10 minutes ago, GreenSock said:

You probably won't notice any real-world difference, but the first one is technically cheaper performance-wise because you don't have to loop through all the properties to adjust for the easing. Plus the 2nd version (helper function) is technically tapping into private properties that might change in a future update. So unless you really NEED the easing adjustment of that 2nd solution, I'd definitely stick with the first. 

 

If you're concerned about performance, you definitely shouldn't be changing top/left values frequently like in your demo. Just use transforms (x/y). In almost every case that I've seen, performance problems have nothing to do with the GSAP code and everything to do with graphics rendering performance in the browser. So make sure you're obsessing about the right things  

 

No, but pretty much anything is possible to do with the current platform. I think it'd be much better for you to explain what you're trying to do from more of a macro level because sometimes I see people getting super caught up in the minutia of a very particular technical issue but their overall approach from an engineering standpoint needs an overhaul and if they did that, it'd greatly simplify or eliminate a lot of their challenges. 

 

Why do you feel the need to use DynamicPropsPlugin? Are your values constantly changing? Why? There may be an entirely different approach that'd end up being more performant and there'd be no need whatsoever for a DynamicPropsPlugin. 

 

If you can provide a super clear minimal demo illustrating the challenge you're facing, that'd be helpful. Just the most basic thing you can think of (a few colored <div> elements) is fine. Your earlier demos were great. 

I just made a quick function which allows me to update variables and pass a boolean to either run the “slow” easing-adjusting code or the faster code.

 

Yea, I just changed top/left values in the CodePen for visualization. I mainly work with HTML5 canvases and need to change lots of object positions with GSAP.

 

About the DynamicPropsPlugin, It's not really required right now. Might be a QoL thing, especially if it would have very good performance. But if its not available, that's perfectly fine and not a big deal.

 

Thank you so much again for your help!