Skid X

Hi Diaco, well, the result is still not totally fluid, but it improves a lot! Thank you very much!

Hi, testing on IE 11 I'm experiencing a really bad animation rendering. As you can see on the Pen, it is a deadly simple animation: one single div with an image scaling and translating. On Chrome it is perfectly fluid. On IE instead it is really choppy. I tried force3D both enabled and disabled: no changes. I'm on Win7 but a friend with Win8.1 confirmed to me the same result. Am I doing something wrong, or maybe do you know any hack / trick to solve this issue? Thanks

Sorry, it's my fault, I was not totally clear in my previous description. It happens when you have the callbacks on a nested timeline while the pause is on the outer one (all in the same instant). I have a parent timeline in my scenario due to other not related reasons and I forgot to mention it. Putting it in this way the lib behavior seems totally reasonable, so I was going to fix my use case moving all the callbacks on the parent to be on the same level of the pause, and I've noticed something strange, I've reproduced it here: http://codepen.io/SkidX/pen/QbQzzY In the first timeline (A and B boxes tweened) I reproduced my bad scenario with the pause in the parent timeline and the callbacks in the child. The call order is that I have said before, and the tweens animation in backward direction is perfectly symmetrical to that one in forward direction, as expected. In the second timeline (C and D boxes tweened) I just moved the callbacks on the parent, and I noticed two different strange things. 1) the "post pause" is never called before the pause (correct) but the order of execution of "D begin" and "post pause" is not always the same, sometimes it runs the callback first, sometimes refreshing the page and restarting it calls the tween begin event first. It's strange considering that the tween position is forced to a different time offset. 2) Take a look to what happens when you resume after the pause, reach the end and then reverse the animation. In backward direction the D box stops on a different position, it is not symmetrical to the forward animation. The only difference is the position of the callbacks, why is changing also the behavior of the tween? I know that we are talking of some edge cases, but just to understand how it is working. Thanks for any feedback.

Here I am, I've tested your update and seems almost perfect in both forward and backward directions. Just to let you know, the only small difference from what I would love to obtain is that currently if I put callbacks on the same instant of the pause, they are executed in any case regardless their definition order. My test scenario is this (consider each item appended at the end of the timeline without any offset): 1) Tween #1, 1s duration 2) callback "A" 3) addPause 4) callback "B" 5) Tween #2, 1s duration My ideal behavior is having this order of execution (in forward direction): - onComplete of #1 > callback A > Pause then after resuming - callback B > onBegin of #2 Obviously I expect the reverse order in backward direction (excluding onComplete and onBegin that will not fire). With your last update I have this: - onComplete of #1 > callback A > callbackB > Pause then after resuming onBegin of #2 Putting just a microsecond of offset among each callbacks and the pause solves the order, it is not a big issue, so feel free to ignore me on this thing if you don't find any value added in changing it Please let me know only if you would consider it as a future change. Thanks a lot for your update, it definitely helps me.

Hi Jack, thanks a lot, I'll make some tests this afternoon (CET timezone here) and let you know. You are totally right when you say that is impossible to achieve exactly the same behavior across different engines, it's very true, but that is also out of the scope of my lib. It would (teorically) require to handle manually any low level aspect of the rendering process, and this is exactly what I do NOT do with Tweene, at the end of the process the single tween is always demanded to the engine of your choice, so it goes out of my control. The aim is to offer to developers a more standardized approach in their work. You can think at it like web standards work with browsers. You can use the same language (CSS) to define styles for any browser, and in most of the cases you will also achieve the same visual result, but there are also a lot of cases handled differently by different browsers, because they run different rendering engines. Without a standardized CSS language, you would have not only different rendered results, but also to learn different style languages and different approaches for different browsers, which is clearly a worse scenario. With Tweene I'm trying to offer a common language and achieve the more reliable result in most of the common cases, not to solve any differences in the inner animation engines. For example Tweene supports also CSS Transitions. As you obviously know, you have no guarantee that two or more transitions of same duration will really end at the same instant, so it is basically impossible to guarantee a perfect sync while it's not an issue in gsap in which all things are in perfect sync by design. I cannot solve this and I don't want to. It's out of my scope. Let' say a developer writes a simple animation using Tweene and CSS Transition as inner engine. Later, that developer comes to the idea that achieve a perfect sync is a requirement for that work. It can just switch the engine from "transit" to "gsap", and in most of the cases no more efforts would be required. I think it's a better scenario than rewriting the whole thing having to learn a different API too. If its animation implies also some corner cases due to the internal differences of the two rendering engines, those differences would be there to solve in any case, with or without Tweene. Said that and coming back to timelines, as you can imagine my implementation of timeline on top of different engines that I cannot control at low level can work only as an advanced "scheduler". Basically I organize the whole thing as a doubly linked list of simple tweens (well, the real structure can be more like a graph, but the list probably gives a better idea of the concept). This approach clearly introduce some small delays on "keyframes" on the timeline, while in your native implementation of timelines this is handled perfectly without any additional overhead. I know, there are of course implicit limits in this approach, but again, if this is an issue for the user, he can choice the tweene's gsap driver that relies on your native timeline implementation, he will have just a really small overhead before the very first play, after that the animation is totally powered by your lib. Since I cannot obtain a cross-engine perfect sync, I tried at least to obtain always the same order of execution of different items (tweens and callbacks) and that was the point of the pause issue. A user talked to me of a simple scenario: a sequence of different tweens one after each other (no overlapping) with a pause just at the end of each tween. With my "timeline as a scheduler" I can do this so "complete event > pause > begin of next tween" are intrinsically always executed in the same order, while the inner optimization that you perform inside your code for events that happens inside the same tick (which is totally a feature from a performance point of view!) made difficult to me to achieve the same order of execution. As told, I'll try today your changes and let you know. Thanks a lot again! (and sorry for my bad english)

Ok, no problem. Thanks!

Searching for a solution, I've found a method that seems perfect when running in forward direction, but it seems really strange (buggy?) when the animation runs reversed. This is my idea: since the addPause() works very well when it is at the same nesting level of other events (tweens that begin almost at the same time or callbacks) while it has some issues when it is positioned on an upper level (that is where I need it), I've put an addPause() at both levels, with the inner one that is "auto resuming" (I've put a child.paused(false) inside the pause callback). This works perfectly in forward direction. The child callbacks are called always before those in the parent (this suggest me that you are using a bottom-up strategy when it is running forwards), so the inner pause is executed first preventing the following events to happen (that is what I need), then it resumes itself but in the same tick it runs the parent pause too, so the overall effect works, and you need just the smallest offset for the following tweens (I'm using one microsecond). I've put also two callbacks for cheching the order of execution, one just before the pause and another one just after it. In forward direction the order is kept perfectly. When you resume it reaches the end of the timeline as expected. The problems come when you reverse it. In backward direction it executes first the parent pause, that seemed coherent to the previous results, bottom-up in forward direction, top-down in backward direction, so I was expecting the child pause to be executed after it. But when you resume it from the pause you see that both the child pause and one of the other callbacks are never executed. So it seems that running in backward direction a pause at the top level "hides" the execution of any callback or pause in the nested items that belong to the same tick. Could you confirm this as a bug or I'm missing something here? Here is the pen when you can see the issue: http://codepen.io/SkidX/pen/pJWqjz

yes, I know it worked incrementing the time offset, but reaching a "safe" offset value, it brings us to the fact that in that way it works also replacing the addPause() with a plain callback having a timeline.pause() as its first instruction, which was our starting point, making the addPause() not so reliable in the way I need it. I really appreciate your efforts, you have a great customer support here (not talking about the fact that it's saturday!), but probably telling you something more about my needs would make it clearer why I'm not so much comfortable with this kind of solution. I'm the author of Tweene (tweene.com), it's a library that works as a proxy of animation libraries (currently your lib, velocity, transit and jquery). Basically it could be used as a layer of abstraction on top of your lib, so the users could arbritrary create any kind of animation with it. My task here is to make the more consistent result across different libraries, so the users can switch, for example, from css transitions or jquery to gsap without changing a single line in their animation code, expecting a reliable result. Since I'm able to solve this pause issue on all the other libraries (because they have not native support for timelines, so I implemented them inside Tweene), it would be really a pity to add an exception for gsap saying something like "to be sure to achieve the same result in gsap, you need to put an offset of 20ms after any pause", My aim is to give more power and more freedom to users, not more constraints. Your lib is the most powerful on the market and my personal favourite too, so I clearly don't want to make it work worse nor perceived as working worse when used together with Tweene. I'm already using internally an offset in gsap driver for solving some corner cases, but I'm using a value of 1microsecond, correcting each duration accordingly so it's totally transparent for the final user. Introducing an extra offset of 20ms or something similar would be really harder to handle in a coherent way. This is the only reason for which I'm struggling (and probably bothering you, sorry for that) to find a robust and general solution that could be applied to any scenario. If it was needed only for a personal specific animation on which I had total control, that solution you have proposed would fit perfectly.

Hi, I've just made a little change in your pen, and it seems to not work as expected also using the addPause() method. If you move the addPause() from the inner timeline to the outer one, you have exactly the same problem that I had in my first example, the second tween starts in any case, also if it begins on a time position after the pause action. Plus, it seems also weird, because the first time when the pen runs automatically, it executes both the onStart event and the first frame of the second tween; when you hit "restart" it executes only the onStart event without changing the element's position, and executes it before the callback associated to the addPause action. Using "restart" sometimes randomly runs correctly as expected, most of the times it doesn't, so it seems strictly related to how quick it is running the addPause, as it was in my first example that used a generic callback. You can see it here: http://codepen.io/SkidX/pen/yNzqeR Unfortunately, this scenario with nested items with the pause on the top level is exactly my use case, so is a real issue for me.

Thanks a lot, your explanation is very clear. This thing brings me to another doubt: is it correct to suppose that also if I put two callbacks at slightly different positions - let's say the first at 1.0s and the second at 1.001s, with the first callback changing the main playhead position (it could be not only a pause() but also a reverse() or a jump to a different time position) it's NOT guaranteed that the second callback wil not be fired? I'm wondering how to obtain a general way to handle a strictly serial execution of an arbitrary sequence of callbacks / tweens honoring also any actions that change the playhead. Knowing in advance the kind of actions involved, the solution is easy (use the addPause method as you suggested, execute the linked callback and then change the playhead OR resume the timeline execution) but there could be cases in which you don't know in advance what the callback needs to do... I have to think about it. Any suggestion is welcome. Anyway thanks a lot, your explanation will help me a lot.

Hi, I'm having some troubles because the order of execution of callbacks and events seems different when I have nested timelines. I have reproduced a simple scenario: I have a timeline with a tween, then a call to a function that pauses the timeline, then another tween. Both tweens are "fromTo" with immediateRender = false. I have added also complete callback on the first tween and start callback on the second one in order to log them. The result is: - first tween completed - timeline paused The second tween is not starting and its start callback is not executed, as I would expect. Then, I take an identical timeline, and I nest it inside another one. In this case the result is: - first tween completed - run the callback that pauses the timeline - first frame of the second tween executed and its start callback executed - timeline actually paused So only nesting the same timeline, the behavior is different. Consider also that this happens also putting the pause action inside the complete callback of the first tween. The second tween starts in any case before the pause takes effect on the timeline. You can see it clearly in the codepen. Is there something wrong in my setup? Is there a way for having the same execution order in any nested or not nested scenario, except putting tweens and callbacks in slightly different positions? Thanks in advance

hi, thanks for the answer, no problem for the timing, no hurry, it's not a blocking issue for me. Yeah, during my experience with your libraries I've seen that using some +0.0001 offset helped me to solve some corner cases quickly. In this specific case, I'm still thinking that it is a bug because also without considering the first example with red block, in the second one we have different behaviors on the loop iterations after the first one and this is not what a user expects in any case. However it's just my humble opinion, I don't want to push you in any way, my aim is just to let you know that this happens, then you will see how to handle it in the best way

As you suggested, I have updated the pen without relative values and with x and y values on both begin and end states of fromTo() method, so it is more clear the issue: as you can see, the blue one plays as the red in the first loop iteration, while it does not reset the y correctly on the next iterations. Also when you restart it, it starts from the wrong y position, while the red restarts correctly.

Hi, as you can see in the Codepen example, I'm seeing different behaviors when using fromTo() nested in two timelines. First case (work as expected): var t1 = new TimelineMax({paused: true, repeat: 2}); t1 .to("#redBox", 1.5, {x: 300}) .fromTo("#redBox", 1.5, {y: '+=100'}, {x: '+=250', immediateRender: false}, "+=0.5"); Second case (work as expected only once, then from the second iteration it seems to not reset the "from", ignoring "immediateRender = false" config value). var t2 = new TimelineMax({paused: true, repeat: 2}); t2 .to("#blueBox", 1.5, {x: 300}) .add(new TimelineMax().fromTo("#blueBox", 1.5, {y: '+=100'}, {x: '+=250', immediateRender: false}), "+=0.5"); Is there something wrong in my setup or is it a bug? Thanks in advance.

great. In fact I've never noticed any slowdown using your libs in my real cases (except on some old low-cost mobile devices, but there I'm sure it wasn't an issue related to one or more callbacks added), but just to be sure it doesn't imply lot of stuff internally. Thanks for the clear explanation.

Ok, the timeline + callbacks solution seems the easiest way. Thanks for the advice. Since we are talking about it, I've another question if you don't mind. Apart from this specific case, making an "emulated" delay with a timeline that contains a callback + a tween (without delay) does imply any valuable overhead in respect to achieve the same result with a single tween with delay? (let's say using always this solution, so potentially for a significant amount of simultaneous tweens) I'm asking because I find the Timeline object much more versatile in most of the situations, so I'm wondering if I could use it also if it is not strictly needed without compromising the overall throughput of my script.

Yeah, this is totally reasonable and it's the reason for the question mark after "bug" in the title, because from two different points of view both the behaviors (the current one and that one expected by me) seem correct. Anyway, I'm ok with the current behavior in most of the situations, but I would like to find a way to achieve the other behavior too, if there is one, so suggestions will be very appreciated. Thank you very much for the quick reply.

Hi, let's say we have a tween moving an element from point A to point B. We have repeat = 2 and repeatDelay = 1s. When it plays in forward direction, it goes from A to B and then executes the repeatDelay while staying at point B (the end point of the tween). After the delay, it jumps back to A for the next loop. Ok, when it plays in backward direction, it goes from B to A but then, instead of executing the repeatDelay staying at point A (its end point in that direction), it jumps immediately back to its starting point B, waiting there for the repeatDelay. So it seems to me that the reversed version of the tween is not the symmetric with the forward one. Am I wrong? is there any way - I don't now, maybe some config param - for forcing it to have the same behavior in reversed direction? Here you can find an example of the issue. Just click on the div in order to let it go forward or backward. http://codepen.io/anon/pen/qnxpd

Yes, thanks.

Sorry, my english sucks, I try to explain better. Before your last update, during drag events this.x and this.y values referred always horizontal and vertical offsets also if the parent was rotated. So I was wondering if now, after your update, this.x and this.y refer to already transformed values (so for example if parent is rotated by 90deg and then I drag the child +50px horizontally relative to the screen, then this.x will not change while this.y will be -50px) or if the library now offers two couple of properties (using my previous example: this.x = +50px, this.y = 0, this.relativeX = 0, this.relativeY = -50px). Or maybe there is a third case: you have left the values of this.x and this.y unmodified and you have fixed only the real position of the DOM element without adding any other public properties. I don't know any available tool that works like you said, it would be definitely a "must-have"!

Great, thanks! I will test it in next week, and will provide feedback if needed. Just a question: does it offer only x and y properties (now transformed) or are there a couple of properties (like "before" and "after" transformation)?

Yes, of course. I've proposed that solution for any users that could have my same scenario or a similar one, not as a bulletproof fix for the overall library. As you told, clearly going up the tree every time and making all those checks and operations also when not needed is not suitable as a default behaviour. Just a simple suggestion for users in the same trouble as mine

Hi, I would like to report a bug found using Draggable (great library!), hope this is the right place. If you drag an element (x,y) inside a parent that has been previously rotated, then this.x and this.y values inside the onDrag callback refer to horizontal and vertical directions, ignoring the fact that the parent is rotated. The result is that if, for example, you rotate the parent by 90deg, when you drag the child horizontally it moves vertically and viceversa. The fix however seems easy. Let's say we have the angle of the parent rotation expressed in degree in the variable 'angle'. Then inside the callback onDrag: angle = - angle * Math.PI / 180; var cosAngle = Math.cos(angle); var sinAngle = Math.sin(angle); var relativeX = (this.x * cosAngle) - (this.y * sinAngle); var relativeY = (this.x * sinAngle) + (this.y * cosAngle); relativeX and relativeY are now the corrected values relative to the parent of the Draggable element. Hope this could be useful. Thanks for your great libraries.