Jump to content
GreenSock

Maarten

Members
  • Posts

    2
  • Joined

  • Last visited

Maarten's Achievements

0

Reputation

  1. Great stuff about the timing guys! I knew setTimeout isn't reliable, that's why i included: Because that is actually how i discovered this behaviour, by clicking right at the time a tween finishes and starting a new tween in the click handler. So the point wasn't really about timing or using setTimeout, i just used it in the example because it triggers the exact same behaviour as i had with my click handler (which is a little hard to demonstrate in JSFiddle ) In my case it was like an open/close toggle. Where onOpenClick adds content to an element and tweens it to become visible, and onCloseClick does kind of the reverse, it tweens to become invisible and onComplete removes the content from the element. So when clicking right around the time the close tween ends, caused the open tween to .. well tween but after that tween started (/was created), the onComplete of the close tween was called which removed content from the element. So it tweened open with empty content. Your post explains the behaviour perfectly There's probably precisely one 'tick' difference (in one way or another) in the starting & rendering (thereby overwriting) of the second tween in which the first one finishes (calling the onComplete). Perfect! That indeed solves the issue. So i guess i'll use this in every tween where i use other tweens on the same target with an onComplete handler. Thanks!
  2. I just stumbled upon this OverwriteManager behaviour that seems to be a bug. When starting a tween with a time of 0.25s and an onComplete handler and then starting a second tween of the same property (that should overwrite/kill the first tween) around the time the first tween completes (i.e. after 250ms via a setTimeout or in a click handler when you click after 250ms), it doesn't fully kill the first tween, so the onComplete handler still fires after the second tween has been started. The onComplete handler is probably called asynchronously in some way. But the asynchronous callback id's (e.g. return values of setTimeout or setInterval) should be saved with a tween untill they are executed, and killed (via clearTimeout / clearInterval) when a new tween overwrites a previous one. I've provided a simple JSFiddle example that displays this behaviour. http://jsfiddle.net/4Vx4P/ Run a few times if it doesn't show the 2 outputs (it's a timing issue). Tested in Chrome and FireFox. Just thought i'd share this with you. Otherwise an awesome product obviously!
×