Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Skid X

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

4 Newbie

About Skid X

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. Hi Diaco, well, the result is still not totally fluid, but it improves a lot! Thank you very much!
  2. 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
  3. 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 an
  4. 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): - o
  5. 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 standa
  6. 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 forwa
  7. 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 t
  8. 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
  9. 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
  10. 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
  11. 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 kno
  12. 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.
  13. 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
  14. 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.
×