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.

.isActive let's me know if my tween is actively updating values (natch). But is there a way to check if I am in a delay? Please see my simple codepen for example.

Thanks Jack. DId not not know about that... will snag!

twn.progress() will give you your percentage through a tween. But Is there a way to get your eased percentage through a tween? The way I am thinking to do it 'out of the box' is to tween a variable from 0 to 1 (along with my other values) and check that variable on update. But would be super if there is an 'in the box' way I have overlooked. Thanks!

No browser extensions installed. This is on Chrome Version 60.0.3112.78 (Official Build) (64-bit) running on macOS 10.12.6 (16G29). As you see in the video, the initial load does not have the large stack trace. Those come with subsequent reloads.

In looking at my original post, I do not see where my codepen link is... so here it is: https://codepen.io/jedierikb/pen/YxWXez?editors=0010

I have recently noticed some large stack traces in my javascript console when debugging greensock tweens in chrome. If you look at the example codepen url, you will see that `requestAnimationFrame (async)` is called repeatedly on every `onUpdate`. I think something has changed in Chrome, as I don't ever recall seeing such long callbacks when debugging before. Any suggestions how to reduce/suppress those stack traces? (And out of curiosity, what's going on to cause those stack traces?) Thanks!

I have an element tweening filter to contrast(0.5) over a minute and then, based on user action during that minute might also have to tween filter to blur(3px) over just a few seconds. I worked around this using a proxy object and creating the filter string on onUpdate. Wondering if this is the sort of thing that making myself a plugin would be good for [1]? Is there a plugin example more aligned with what I am describing for reference? Thanks! [1]

Any development on this? I find I often use gsap to position elements with complex transforms, so performance for handling translate percentages is not a problem.

Of course, it looks like the proper way to do this is to use the Draggable's onClick events, but I got snagged retrofitting some code and using existing event handlers.