erikb

All okay on my end, thank you. Came across the discrepancy while going through some logs, so I reported it.

It seems that parseEase('linear') and parseEase('none') return different functions? https://codepen.io/jedierikb/pen/VwEeJGz

I suppose you are right - tween goes first, and that queues a repaint. Yes, you are right. I guess I am wondering if there is a way to ensure that react will render on the same rAF that the tween onUpdate was called from... (assuming react is queuing updates on the rAF, which is looks like it does). OR maybe that is an abstraction barrier I don't need to worry myself about

Was curious about timing issues between react and greensock. Specifically, was curious about onRequestAnimationFrame priority when tweening vanilla js objects passed into React setState to change how elements are rendered in the React render() call. So, I built my codepen to see if react or greensock would go first - and it seems, based on console output of Tweenmax.ticker.frame, that greensock updates first, and then react renders (which is what I would want to happen on every tick). I am aware this is a different way of using react and greensock than what you've published here - - but for many of my use cases, I tween through a proxy object, hence my inquiry. I am wondering - is there a way to ensure that greensock is called first 'on the tick' before react render calls are made? Where / how would this sort of thing be coordinated and set between the two libraries? I took a gander at the react source at https://unpkg.com/react@16.9.0/umd/react.development.js specifically around `requestHostCallback` where there is instructions on how to use rAF. Not much I see on first pass regarding prioritization with other libraries. Your insight into this issue and advice greatly appreciated. Thank you!

Thank you, that is a good idea re: ratio.

Programmatically setting a tween with duration 0 results in progress calls returning NaN. I expected 1. This is an edge case, but seemed worth reporting as it caused me to stumble. Thank for taking a look at this issue and happy tweening to you all.

Alas, vue has changed considerably since I was working on this project. Sorry.

Thanks, and good idea how to get at the information I want.

Is there a way to query the ticker for the priority (.pr) of the last dispatched event? This would be real helpful at times.. especially when dispatching custom events before and after tweens and wanting to know where we are in the series of events. For example, would want to be able to query TweenMax.ticker if I am at priority -100 or 100 from when these are fired: TweenMax.ticker.addEventListener('tick', preComponentPaintCb, this, false, -100 ); TweenMax.ticker.addEventListener( 'tick', postComponentPaintCb, this, false, 100 ); My research suggests this information is not available... and if I wanted to add it, I would so hereabouts: https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/TweenMax.js#L6320 by adding something like this.lastPr = listener.pr; Help and suggestions appreciated. I've a related question but will hold on until I get some feedback on this one Thanks!

Yes, that is helpful! Thank you all for explaining how to best understand this use of your library.

Alas, timeline.smoothChildTiming = true did not seem to do the trick. FWIW, here are two demos next to each other showing the desired behavior of the two tweens and the not desired behavior I get when they are added to a timeline: [1] Here is a codepen with two tweens not added to a timeline. At the 5 second mark, the red square has updateTo called on it and it accelerates to its new target. This is desired visual behavior: [2] And, here is a codepen with the tweens added to a timeline. At the 5 second mark, the red square has updateTo called on it and it is moved back to its origin before accelerating to its new target (effectively restarting the tween):

If resetDuration is set to false there are no hiccups (yea!). This works if the tweens are added or not added to a timeline. In my example under those conditions, the two tweens take 10 seconds to complete and look great. However, if the tweens are added to a timeline and then resetDuration is set to true, one tween apparently restarts when onUpdate is called. Compare this to when the tweens are not added to a timeline -- no hiccup/restart and the total time of the animation is ~15 seconds. This is the visual behavior I was looking for. What am I trying to accomplish? My goals (which led to my original post): - Get a callback when both tweens have been updated. This is why I thought to put the tweens into a timeline. - When one/both of the tweens has updateTo called on them, do _not_ set resetDuration to true, but instead to extend the duration of the tween. A solution I came up with (which works for me!) was to not use a timeline and instead I keep track of every tweens' onUpdate. Since I know how many tweens there are, I can count their onUpdate callbacks and when they've all fired I do my all-tweens-are-done logic then.

Sorry for the obtuse code. I've cleaned it up some and hope this is easier to grok. You can change the behavior which adds the tweens to a timeline by toggling the variable addToTimeline to true.

I am tweening a few javascript objects. I use onUpdate to move things on screen and they tween like butter. Sometimes I call updateTo on the tweens and they update like the blue angels in fighting formation. However, I need to check all of these objects' values after each has tweened to ensure they remain in some bounds. I thought the way to do this was to put them into a timeline since the timeline's onUpdate is called last. However, I've hit a snag -- when the tweens' updateTo are called, now that they are in a timeline, the tweens are restarted? My workaround is to do my own bookkeeping and when the last of my objects has been tweened, then I will do my boundary checks. Or is there a way to use a timeline in this unconventional way? Thanks.

Yes, thank you. And i see how i can determine how far into the delay my tween is with these calls as well.