annam

Hello, we have created a custom easing function for a Spring ease implementation using the following suggestion and it is working great: However we have a problem with the seek function, as you can see from the jsfiddle attached: https://jsfiddle.net/juw06kz5/1/ (the ease code is copied from a compiled typescript implementation - apologies!) Use the play button to see the correct animation, then "Run" the fiddle again to use the slider to seek back and forth. You will see that when using seek, the ease disregards the time requested in seek(x) and moves linearly. When a single "loop" of the total duration of the spring animation has been completed, the only values the seek will respect is seek(0) and seek(1). The problem with the seek, seems to be that the implementation of the SpringRK4 algorithm depends on the previous state of the animation to calculate the new one (http://mtdevans.com/2013/05/fourth-order-runge-kutta-algorithm-in-javascript-with-demo/) You can see this in the jsfiddle, in the step() and integrate() functions. Do you have any suggestions on how to fix this issue? Thanks, Anna

Hi Jack, thanks for this info, yes this did the trick! we were actually using maxDuration: 0 trying to limit this and we hadn't noticed that there was also a minDuration setting. thanks again! Anna

UPDATE 2: it seems that the bounds was affecting it because the bounds were too small for the deceleration to show... increasing the bounds kind of shows a difference in the friction, however it's minimal even if we set the throwResistance setting to be ridiculously high.. is this normal? try "flicking" the boxes to the right.. we would expect the second box to slow down immediately, have no momentum at all with such a high resistance value.. this is what we are trying to achieve https://jsfiddle.net/annam/zypagaLe/3/

UPDATE: it seems that this is affected by the "bounds" property? as soon as I remove the bounds setting the difference between the two items' friction in the example is visible.. https://jsfiddle.net/annam/zypagaLe/2/ why is that?

Hello! I'm trying to slow down the item faster after mouse release on drag, but it seems that using any number for the throwResistance variable makes no change to the functionality. Here is the example: https://jsfiddle.net/annam/zypagaLe/1/ Am I wrong in assuming that changing the throwResistance property would affect the speed in which the dragged item would decelerate? If so, what exactly does the throwResistance accomplish? Thanks, Anna

Hi Jack, thanks for the explanation, so if I just use immediateRender: false this issue will be fixed. Is there something else that this might affect? As I mentioned earlier, duration and delay are variable values, do I need to only set immediateRender to false if these values are 0 or can this always be false with no unexpected side effects? Thanks again! Anna

Hi Jonathan, thanks for all the feedback and suggestions, I appreciate it and we will look into adding these improvements. It seems strange that I would need to add a position parameter to to() if the add() delay is 0, but not if it is not 0.01, in which case even though the add is executed later, the to() function seems to understand this and is executed after the add. From what I understand from the docs, both the add() and the to() functions will be added to the end of the timeline if a position parameter is not explicitly passed to them. I guess we could easily work around this issue by passing "+=0.01" as the position to the to() function. We'd like the two functions to run as close to each other as possible, which is why we haven't added any delay to the to() function, and both duration and delay are actually variable values which is why we are using to() and not set(). I just thought i should report this as a possible bug in gsap. Thanks for looking into this! Regards, Anna

Hello we've come across a strange issue today, it seems that some of the functions in a timeline are being executed in the wrong order if they both have 0 duration and they are positioned at time 0 in the timeline: new TimelineMax().add(function () { document.getElementById('box').style.display = 'block'; document.getElementById('box').style.opacity = 0; }, 0) .to('#box', 0, { opacity: 1 }) it seems that in this case the to() will run before the add() function. if i set the add() delay to eg 0.01, then the add() function will run first, as expected. you can find a working jsfiddle here: https://jsfiddle.net/annam/bbxnf2zL/ . try changing the add() delay to see that the rectangle appears as expected if the delay is not 0. DOM breakpoints confirm what i mention above, the opacity is first changed from the to() function and then from the add() function any ideas why this is happening? thanks! Anna

That's good to hear! So if this simple solution does the trick and there are no repercussions then it should be very easy to work around the issue.. Thanks again! Anna

Hi Carl, thanks for the reply, actually, in both questions I was referring not the the creation of the DOM element, but to adding the tween to the timeline through a function and not directly, thus by-passing what I suppose are greensock's performance optimisations. Though of course we understand the consequences of changing the DOM during the animation.. Thanks!

Yes that is a solution we were considering for the .wrap() scenario, to have the dom element somewhere else in the dom beforehand. However that is not the only possible DOM manipulation we may have to do. We'd like a solution that will work for any scenario we come across so that we don't have to individually examine and think of a workaround for every case. Precreating but not attaching the dom element might be technically possible but it would require major rengineering of the code to get this working, and as I said, this is something that we might come across for more than one scenarios..

Hi all, we'd like to build a complex timeline that does various DOM manipulation and animations and has both functions and tweens on it. On the timeline, it first creates some DOM elements dynamically: timeline.add(function(){ $('#box').wrap('<div id="box-outer" />') }, 1) and then, later on in the timeline, we'd like to target that added DOM, to animate it: timeline.add(TweenLite.to("#box-outer", 1, { background: 'red'}), 2) This does not work, presumably because greensock tries to access and cache the DOM elements when we first create the timeline. We have figured out a way to work around this issue by adding the tweens inside functions and not directly on the timeline, as below: timeline.add(function(){ timeline.add(TweenLite.to("#box-outer", 1, { width: 100 }), 2) }, 2); we add to the timeline from inside the function so that we can then have the animation on the timeline and it can be reversed, seeked etc. these are all things that we use. Here is the jsfiddle for reference, just toggle the two solutions to see the difference: https://jsfiddle.net/annam/hfhb5gxr/2/ However, due to the nature of our project, we don't know when this DOM might be missing on timeline creation, and so we will need to add all tweens inside functions and not directly on the timeline. We are worried that this will have a heavy negative effect on performance. Can we have your input on this? WIll this have any other unexpected changes to functionality, eg seek, reverse and so on? I don't suppose there's a hidden setting somewhere that I haven't come across that we can change to have greensock re-search for the DOM element if it doesn't find it? Also please note that this is the second time that we have come across this issue of needing to access newly - created dom: http://greensock.com/forums/topic/8348-reversing-on-recreated-dom/ Thank you! Anna

Hi Jack, yes it works now! Thank you so much, can't wait for the next release! Anna

Hi Jack, thanks for looking into the fix! It actually didn't work for us. We toggle visibility by toggling a class that contains the "display: none" declaration, but when your fix runs it adds an inline "display: none" declaration on the DOM element and the items never get displayed when we remove the "hidden" class. Even if we could work around this, what's alarming is that even if we manually disable the inline "display: none" declaration, the items are incorrectly positioned, as before. Thanks again for looking into this! Anna

Hi Jack, thanks for your concern! this is a recent issue that I can recall that we had to work around it in our own code, however I get that this is a much more complex case.. http://greensock.com/forums/topic/13449-seek-causes-timeline-to-jump-on-transition-when-two-similar-tweens-are-found/#entry56122 What I meant with my post above is that, if you were to check for this issue, all you'd need to check on all elements you are animating (which would affect performance) would be if they are display: none or not. if not, then you'd need to perform no further actions.. so the only overhead would be an "is visible" check. in the cases where this does happen of course you would need more code of course, but that's to fix an issue where the tween wouldn't be played correctly if it wasn't there.. Anyway, that's my idea of the fix by your description above, and with very limited knowledge of your code.. I'm sure things are actually more complex The difficulty with applying the suggested fix for us is that, as this could happen on any property transition, we need to add the code for possibly adding the "display: none" in the tween in many, many places. Thanks! Anna