Jump to content
Search Community

time inconsistencies

blase test
Moderator Tag

Recommended Posts

i have noticed this before.

 

i have a loop with delay, maybe a few loops, and then few delayed calls after:

 

var bottomDelay:int = 0;
for (var k:int = _bottomIndex - _lineItems; k < _bottomIndex; k++) {

TweenLite.to( _thumbArr[k], _shiftTime, { y: String( _verticalShift), alpha:0, ease: _ease, delay: bottomDelay * _delay });

bottomDelay ++;

}

// the loop repeats _lineItems times if you are wondering, because i dont start at 0 index

TweenLite.delayedCall( _shiftTime + _lineItems * _delay, _filter.dispose ); 

TweenLite.delayedCall( _shiftTime + _lineItems * _delay, controlIndex, [ - _lineItems ] ); 

TweenLite.delayedCall( _shiftTime + _lineItems * _delay, checkButtons ); 

 

now, what happens is that sometimes ( for example ) first delayed call is executed before loop has ended and that breaks everything.

i have come around this by increasing time to delayed call, but this solution is kind of sluggish to me :mrgreen:

 

 

 

i would like to switch to version 11 but i dont have time to learn actionscript and tweening engine :D

(although obviously that day will come eventually )

Link to comment
Share on other sites

If you schedule two tweens to occur at EXACTLY the same time (and a delayedCall is just a tween with a delay and an onComplete), the one you created last will be executed before the one you created earlier and there's a very important reason why: overwriting. This one of the things that makes the engine so reliable. Let's say you have the following:

TweenLite.from(mc, 1, {x:100, immediateRender:false});
TweenLite.to(mc, 1, {x:500});

 

If the first tween was allowed to run first before the 2nd one overwrote it, the x position would be in a completely different spot when the 2nd tween initializes, causing it to act as though the first tween wasn't properly overwritten.

 

So if you want your delayedCall to run after the others, add a little time to it (0.001 seconds should be fine). There's really no elegant way around this issue from what I can see, and overwriting behavior is much more critical to the reliability of the platform, so I must prioritize that.

Link to comment
Share on other sites

wait a minute, you want to say that this 3 lines make 3 tweens?

 

TweenLite.delayedCall( _shiftTime + _lineItems * _delay, _filter.dispose );
TweenLite.delayedCall( _shiftTime + _lineItems * _delay, controlIndex, [ - _lineItems ] );
TweenLite.delayedCall( _shiftTime + _lineItems * _delay, checkButtons ); 

 

i didnt know that, i thought this was treated like a "normal" 3 function calls in a row...

thats why i was having all these problems....

 

on more thing: does this mean that delayedCall can even overwrite my for loop? (or the last occurence in my foor loop)

 

so if i had these 3 lines written like that what would be their executing order?

 

and if i want to do this like i intended then it should look like this?

 

TweenLite.delayedCall( _shiftTime + _lineItems * _delay, _filter.dispose );
TweenLite.delayedCall( _shiftTime + _lineItems * _delay + 0.001, controlIndex, [ - _lineItems ] );
TweenLite.delayedCall( _shiftTime + _lineItems * _delay + 0.002, checkButtons ); 

 

now i wonder whats the actuall gain in using delayed calls instead of (not so) simple timer or setTimeout...

Link to comment
Share on other sites

does this mean that delayedCall can even overwrite my for loop?

 

Nope, delayedCalls always have their overwrite set to false, so you don't need to worry about any overwriting occurring. And remember that overwriting is only a factor when there are multiple tweens of the SAME OBJECT. It's not as though you can only have one tween going at any time - TweenLite/Max only consider tweens of the same object when doing overwriting.

 

and if i want to do this like i intended then it should look like this?

 

TweenLite.delayedCall( _shiftTime + _lineItems * _delay, _filter.dispose );
TweenLite.delayedCall( _shiftTime + _lineItems * _delay + 0.001, controlIndex, [ - _lineItems ] );
TweenLite.delayedCall( _shiftTime + _lineItems * _delay + 0.002, checkButtons ); 

 

Yep, that'd work.

 

Now i wonder whats the actuall gain in using delayed calls instead of (not so) simple timer or setTimeout...

 

There are several reasons to use delayedCall() instead of setTimeout or Timer:

 

1) There are bugs in Flash's setTimeout(), especially on the Mac platform

 

2) All delayedCalls to a particular function can easily be canceled with TweenLite.killDelayedCallsTo(myFunction). To do that with a setTimeout() or Timer would require you to keep references to each one and manually cancel them all (much more cumbersome).

 

3) delayedCall() will perform better because the timing mechanism is built into the core TweenLite class. Every Timer instance you create has its own timing mechanism, so the more Timers you have, the more duplicated logic Flash must run, slowing it down.

Link to comment
Share on other sites

ok, one more question... for example if i have a loop with a delay like so:

for (var i:int = 0; i < 10; i++) {
TweenLite.to( _thumbArr[i], _shiftTime, { y: 0,  delay: i* _delay });
}
TweenLite.delayedCall( _shiftTime + 10 * _delay, myFunction ); 

or like so:

for (var i:int = 0; i < 10; i++) {
TweenLite.to( _thumbArr[i], _shiftTime, { y: 0 });
}
TweenLite.delayedCall( _shiftTime, myFunction ); 

 

will it work as i intended if my delayed call times are the same as time of the loops or do i need to increase that time?

 

(i wouldnt want to call myFunction before loop finishes)

 

 

btw, is there a way to find out when your tweens have been overwritten?

Link to comment
Share on other sites

I'm not entirely sure of your intent, but let me summarize how the rendering queue works: tweens of the same object that begin at EXACTLY the same time will be rendered from the last one you created to the first so that overwriting occurs correctly. I'd recommend using trace() to verify exactly how it will work in your specific scenario.

 

And no, there isn't a way to tell when a tween has been overwritten. One of the goals of the platform is to keep things very fast and small, so events are not dispatched every time a tween is overwritten.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...