var_gsScope=(typeof(module)!=="undefined"&&module.exports&&typeof(global)!=="undefined")?global:this||window;//helps ensure compatibility with AMD/RequireJS and CommonJS/Node
if(t.vars.time!==t.target.time()&&duration===t.duration()&&!t.isFromTo){//don't make the duration zero - if it's supposed to be zero, don't worry because it's already initting the tween and will complete immediately, effectively making the duration zero anyway. If we make duration zero, the tween won't run at all.
t.duration(Math.abs(t.vars.time-t.target.time())/t.target._timeScale).render(t.time(),true,true);//render() right away to ensure that things look right, especially in the case of .tweenTo(0).
}
if(vars.onStart){//in case the user had an onStart in the vars - we don't want to overwrite it.
vars.onStart.apply(vars.onStartScope||vars.callbackScope||t,vars.onStartParams||[]);//don't use t._callback("onStart") or it'll point to the copy.onStart and we'll get a recursion error.
if(prevTime!==self._time){//if totalDuration() finds a child with a negative startTime and smoothChildTiming is true, things get shifted around internally so we need to adjust the time accordingly. For example, if a tween starts at -30 we must shift EVERYTHING forward 30 seconds and move this timeline's startTime backward by 30 seconds so that things align with the playhead (no jump).
time+=self._time-prevTime;
}
if(time>=totalDur-_tinyNum&&time>=0){//to work around occasional floating point math artifacts.
if(!self._locked){
self._totalTime=totalDur;
self._cycle=self._repeat;
}
if(!self._reversed)if(!self._hasPausedChild()){
isComplete=true;
callback="onComplete";
internalForce=!!self._timeline.autoRemoveChildren;//otherwise, if the animation is unpaused/activated after it's already finished, it doesn't get removed from the parent timeline.
self._rawPrevTime=(self._duration||!suppressEvents||time||self._rawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration timeline or tween, we need to discern if events are suppressed so that when the playhead moves again (next time), it'll trigger the callback. If events are NOT suppressed, obviously the callback would be triggered in this render. Basically, the callback should fire either when the playhead ARRIVES or LEAVES this exact spot, not both. Imagine doing a timeline.seek(0) and there's a callback that sits at 0. Since events are suppressed on that seek() by default, nothing will fire, but when the playhead moves off of that position, the callback should fire. This behavior is what people intuitively expect. We set the _rawPrevTime to be a precise tiny number to indicate this scenario rather than using another property/variable which would increase memory usage. This technique is less readable, but more efficient.
if(self._yoyo&&(self._cycle&1)){
self._time=time=0;
}else{
self._time=dur;
time=dur+0.0001;//to avoid occasional floating point rounding errors - sometimes child tweens/timelines were not being fully completed (their progress might be 0.999999999999998 instead of 1 because when _time - tween._startTime is performed, floating point errors would return a value that was SLIGHTLY off). Try (999999999999.7 - 999999999999) * 1 = 0.699951171875 instead of 0.7. We cannot do less then 0.0001 because the same issue can occur when the duration is extremely large like 999999999999 in which case adding 0.00000001, for example, causes it to act like nothing was added.
}
}elseif(time<_tinyNum){//to work around occasional floating point math artifacts, round super small values to 0.
if(!self._locked){
self._totalTime=self._cycle=0;
}
self._time=0;
if(time>-_tinyNum){
time=0;
}
if(prevTime!==0||(dur===0&&prevRawPrevTime!==_tinyNum&&(prevRawPrevTime>0||(time<0&&prevRawPrevTime>=0))&&!self._locked)){//edge case for checking time < 0 && prevRawPrevTime >= 0: a zero-duration fromTo() tween inside a zero-duration timeline (yeah, very rare)
}elseif(prevRawPrevTime>=0&&self._first){//when going back beyond the start, force a render so that zero-duration tweens that sit at the very beginning render their start values properly. Otherwise, if the parent timeline's playhead lands exactly at this timeline's startTime, and then moves backwards, the zero-duration tweens at the beginning would still be at their end state.
internalForce=true;
}
self._rawPrevTime=time;
}else{
self._rawPrevTime=(dur||!suppressEvents||time||self._rawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration timeline or tween, we need to discern if events are suppressed so that when the playhead moves again (next time), it'll trigger the callback. If events are NOT suppressed, obviously the callback would be triggered in this render. Basically, the callback should fire either when the playhead ARRIVES or LEAVES this exact spot, not both. Imagine doing a timeline.seek(0) and there's a callback that sits at 0. Since events are suppressed on that seek() by default, nothing will fire, but when the playhead moves off of that position, the callback should fire. This behavior is what people intuitively expect. We set the _rawPrevTime to be a precise tiny number to indicate this scenario rather than using another property/variable which would increase memory usage. This technique is less readable, but more efficient.
if(time===0&&isComplete){//if there's a zero-duration tween at the very beginning of a timeline and the playhead lands EXACTLY at time 0, that tween will correctly render its end values, but we need to keep the timeline alive for one more render so that the beginning values render properly as the parent's playhead keeps moving beyond the begining. Imagine obj.x starts at 0 and then we do tl.set(obj, {x:100}).to(obj, 1, {x:200}) and then later we tl.reverse()...the goal is to have obj.x revert to 0. If the playhead happens to land on exactly 0, without this chunk of code, it'd complete the timeline and remove it from the rendering queue (not good).
tween=self._first;
while(tween&&tween._startTime===0){
if(!tween._duration){
isComplete=false;
}
tween=tween._next;
}
}
time=0;//to avoid occasional floating point rounding errors (could cause problems especially with zero-duration tweens at the very beginning of the timeline)
if(!self._initted){
internalForce=true;
}
}
}else{
if(dur===0&&prevRawPrevTime<0){//without this, zero-duration repeating timelines (like with a simple callback nested at the very beginning and a repeatDelay) wouldn't render the first time through.
internalForce=true;
}
self._time=self._rawPrevTime=time;
if(!self._locked){
self._totalTime=time;
if(self._repeat!==0){
cycleDuration=dur+self._repeatDelay;
self._cycle=(self._totalTime/cycleDuration)>>0;//originally _totalTime % cycleDuration but floating point errors caused problems, so I normalized it. (4 % 0.8 should be 0 but it gets reported as 0.79999999!)
self._time=prevTime;//temporarily revert _time so that render() renders the children in the correct order. Without this, tweens won't rewind correctly. We could arhictect things in a "cleaner" way by splitting out the rendering queue into a separate method but for performance reasons, we kept it all inside this method.
self._locked=true;//prevents changes to totalTime and skips repeat/yoyo behavior when we recursively call render()
prevTime=(backwards)?0:dur;
self.render(prevTime,suppressEvents,(dur===0));
if(!suppressEvents)if(!self._gc){
if(self.vars.onRepeat){
self._cycle=recCycle;//in case the onRepeat alters the playhead or invalidates(), we shouldn't stay locked or use the previous cycle.
self._locked=false;
self._callback("onRepeat");
}
}
if(prevTime!==self._time){//in case there's a callback like onComplete in a nested tween/timeline that changes the playhead position, like via seek(), we should just abort.
return;
}
if(wrap){
self._cycle=prevCycle;//if there's an onRepeat, we reverted this above, so make sure it's set properly again. We also unlocked in that scenario, so reset that too.
self._locked=true;
prevTime=(backwards)?dur+0.0001:-0.0001;
self.render(prevTime,true,false);
}
self._locked=false;
if(self._paused&&!prevPaused){//if the render() triggered callback that paused this timeline, we should abort (very rare, but possible)
if(prevTotalTime!==self._totalTime)if(self._onUpdate)if(!suppressEvents){//so that onUpdate fires even during the repeatDelay - as long as the totalTime changed, we should trigger onUpdate.
self._active=true;//so that if the user renders the timeline (as opposed to the parent timeline rendering it), it is forced to re-render and align it with the proper time/frame on the next rendering cycle. Maybe the timeline already finished but the user manually re-renders it as halfway done, for example.
next=tween._next;//record it here because the value could change after rendering...
if(curTime!==self._time||(self._paused&&!prevPaused)){//in case a tween pauses or seeks the timeline when rendering, like inside of an onUpdate/onComplete
self._pauseTime=pauseTime;//so that when we resume(), it's starting from exactly the right spot (the pause() method uses the rawTime for the parent, but that may be a bit too far ahead)
next=tween._prev;//record it here because the value could change after rendering...
if(curTime!==self._time||(self._paused&&!prevPaused)){//in case a tween pauses or seeks the timeline when rendering, like inside of an onUpdate/onComplete
pauseTween=tween._prev;//the linked list is organized by _startTime, thus it's possible that a tween could start BEFORE the pause and end after it, in which case it would be positioned before the pause tween in the linked list, but we should render it before we pause() the timeline and cease rendering. This is only a concern when going in reverse.
self._pauseTime=pauseTime;//so that when we resume(), it's starting from exactly the right spot (the pause() method uses the rawTime for the parent, but that may be a bit too far ahead)
if(_lazyTweens.length){//in case rendering caused any tweens to lazy-init, we should render them because typically when a timeline finishes, users expect things to have rendered fully. Imagine an onUpdate on a timeline that reports/checks tweened values.
_lazyRender();
}
self._callback("onUpdate");
}
if(callback)if(!self._locked)if(!self._gc)if(prevStart===self._startTime||prevTimeScale!==self._timeScale)if(self._time===0||totalDur>=self.totalDuration()){//if one of the tweens that was rendered altered this timeline's startTime (like if an onComplete reversed the timeline), it probably isn't complete. If it is, don't worry, because whatever call altered the startTime would complete if it was necessary at the new time. The only exception is the timeScale property. Also check _gc because there's a chance that kill() could be called in an onUpdate
if(isComplete){
if(_lazyTweens.length){//in case rendering caused any tweens to lazy-init, we should render them because typically when a timeline finishes, users expect things to have rendered fully. Imagine an onComplete on a timeline that reports/checks tweened values.
_slice=function(a){//don't use [].slice because that doesn't work in IE8 with a NodeList that's returned by querySelectorAll()
varb=[],
l=a.length,
i;
for(i=0;i!==l;b.push(a[i++]));
returnb;
},
_defaultImmediateRender=function(tl,toVars,fromVars,defaultFalse){//default to immediateRender:true unless otherwise set in toVars, fromVars or if defaultFalse is passed in as true
//for distributing values across an array. Can accept a number, a function or (most commonly) a function which can contain the following properties: {base, amount, from, ease, grid, axis, length, each}. Returns a function that expects the following parameters: index, target, array. Recognizes the following
varvars=(typeof(v)==="object")?v:{each:v},//n:1 is just to indicate v was a number; we leverage that later to set v according to the length we get. If a number is passed in, we treat it like the old stagger value where 0.1, for example, would mean that things would be distributed with 0.1 between each element in the array rather than a total "amount" that's chunked out among them all.
//translates the supplied time on the root/global timeline into the corresponding local time inside a particular animation, factoring in all nesting and timeScales
if(hasNegativeStart){//calling totalDuration() will force the adjustment necessary to shift the children forward so none of them start before zero, and moves the timeline backwards the same amount, so the playhead is still aligned where it should be globally, but the timeline doesn't have illegal children that start before zero.
if(value._time||(!value._duration&&value._initted)){//in case, for example, the _startTime is moved on a tween that has already rendered. Imagine it's at its end state, then the startTime is moved WAY later (after the end of this timeline), it should render at its beginning.
//if the timeline has already ended but the inserted tween/timeline extends the duration, we should enable this timeline again so that it renders properly. We should also align the playhead with the parent timeline's when appropriate.
//in case any of the ancestors had completed but should now be enabled...
tl=self;
beforeRawTime=(tl.rawTime()>value._startTime);//if the tween is placed on the timeline so that it starts BEFORE the current rawTime, we should align the playhead (move the timeline). This is because sometimes users will create a timeline, let it finish, and much later append a tween and expect it to run instead of jumping to its end state. While technically one could argue that it should jump to its end state, that's not what users intuitively expect.
tl.totalTime(tl._totalTime,true);//moves the timeline (shifts its startTime) if necessary, and also enables it.
}elseif(tl._gc){
tl._enabled(true,false);
}
tl=tl._timeline;
}
}
returnself;
};
p.remove=function(value){
if(valueinstanceofAnimation){
this._remove(value,false);
vartl=value._timeline=value.vars.useFrames?Animation._rootFramesTimeline:Animation._rootTimeline;//now that it's removed, default it to the root timeline so that if it gets played again, it doesn't jump back into this timeline.
value._startTime=(value._paused?value._pauseTime:tl._time)-((!value._reversed?value._totalTime:value.totalDuration()-value._totalTime)/value._timeScale);//ensure that if it gets played again, the timing is correct.
//if we're about to add a tween/timeline (or an array of them) that's already a child of this timeline, we should remove it first so that it doesn't contaminate the duration().
clippedDuration=(typeof(timeOrLabel)==="number"&&!offsetOrLabel)?0:(this.duration()>99999999999)?this.recent().endTime(false):this._duration;//in case there's a child that infinitely repeats, users almost never intend for the insertion point of a new child to be based on a SUPER long value like that so we clip it and assume the most recently-added child's endTime should be used instead.
if(typeof(timeOrLabel)==="string"&&(isNaN(timeOrLabel)||this._labels[timeOrLabel]!=null)){//if the string is a number like "1", check to see if there's a label with that name, otherwise interpret it as a number (absolute value).
if(prevTime!==self._time){//if totalDuration() finds a child with a negative startTime and smoothChildTiming is true, things get shifted around internally so we need to adjust the time accordingly. For example, if a tween starts at -30 we must shift EVERYTHING forward 30 seconds and move this timeline's startTime backward by 30 seconds so that things align with the playhead (no jump).
if(time>=totalDur-_tinyNum&&time>=0){//to work around occasional floating point math artifacts.
self._totalTime=self._time=totalDur;
if(!self._reversed)if(!self._hasPausedChild()){
isComplete=true;
callback="onComplete";
internalForce=!!self._timeline.autoRemoveChildren;//otherwise, if the animation is unpaused/activated after it's already finished, it doesn't get removed from the parent timeline.
self._rawPrevTime=(self._duration||!suppressEvents||time||self._rawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration timeline or tween, we need to discern if events are suppressed so that when the playhead moves again (next time), it'll trigger the callback. If events are NOT suppressed, obviously the callback would be triggered in this render. Basically, the callback should fire either when the playhead ARRIVES or LEAVES this exact spot, not both. Imagine doing a timeline.seek(0) and there's a callback that sits at 0. Since events are suppressed on that seek() by default, nothing will fire, but when the playhead moves off of that position, the callback should fire. This behavior is what people intuitively expect. We set the _rawPrevTime to be a precise tiny number to indicate this scenario rather than using another property/variable which would increase memory usage. This technique is less readable, but more efficient.
time=totalDur+0.0001;//to avoid occasional floating point rounding errors - sometimes child tweens/timelines were not being fully completed (their progress might be 0.999999999999998 instead of 1 because when _time - tween._startTime is performed, floating point errors would return a value that was SLIGHTLY off). Try (999999999999.7 - 999999999999) * 1 = 0.699951171875 instead of 0.7.
}elseif(time<_tinyNum){//to work around occasional floating point math artifacts, round super small values to 0.
if(self._timeline.autoRemoveChildren&&self._reversed){//ensures proper GC if a timeline is resumed after it's finished reversing.
internalForce=isComplete=true;
callback="onReverseComplete";
}elseif(self._rawPrevTime>=0&&self._first){//when going back beyond the start, force a render so that zero-duration tweens that sit at the very beginning render their start values properly. Otherwise, if the parent timeline's playhead lands exactly at this timeline's startTime, and then moves backwards, the zero-duration tweens at the beginning would still be at their end state.
internalForce=true;
}
self._rawPrevTime=time;
}else{
self._rawPrevTime=(self._duration||!suppressEvents||time||self._rawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration timeline or tween, we need to discern if events are suppressed so that when the playhead moves again (next time), it'll trigger the callback. If events are NOT suppressed, obviously the callback would be triggered in this render. Basically, the callback should fire either when the playhead ARRIVES or LEAVES this exact spot, not both. Imagine doing a timeline.seek(0) and there's a callback that sits at 0. Since events are suppressed on that seek() by default, nothing will fire, but when the playhead moves off of that position, the callback should fire. This behavior is what people intuitively expect. We set the _rawPrevTime to be a precise tiny number to indicate this scenario rather than using another property/variable which would increase memory usage. This technique is less readable, but more efficient.
if(time===0&&isComplete){//if there's a zero-duration tween at the very beginning of a timeline and the playhead lands EXACTLY at time 0, that tween will correctly render its end values, but we need to keep the timeline alive for one more render so that the beginning values render properly as the parent's playhead keeps moving beyond the begining. Imagine obj.x starts at 0 and then we do tl.set(obj, {x:100}).to(obj, 1, {x:200}) and then later we tl.reverse()...the goal is to have obj.x revert to 0. If the playhead happens to land on exactly 0, without this chunk of code, it'd complete the timeline and remove it from the rendering queue (not good).
tween=self._first;
while(tween&&tween._startTime===0){
if(!tween._duration){
isComplete=false;
}
tween=tween._next;
}
}
time=0;//to avoid occasional floating point rounding errors (could cause problems especially with zero-duration tweens at the very beginning of the timeline)
self._active=true;//so that if the user renders the timeline (as opposed to the parent timeline rendering it), it is forced to re-render and align it with the proper time/frame on the next rendering cycle. Maybe the timeline already finished but the user manually re-renders it as halfway done, for example.
next=tween._next;//record it here because the value could change after rendering...
if(curTime!==self._time||(self._paused&&!prevPaused)){//in case a tween pauses or seeks the timeline when rendering, like inside of an onUpdate/onComplete
self._pauseTime=pauseTime;//so that when we resume(), it's starting from exactly the right spot (the pause() method uses the rawTime for the parent, but that may be a bit too far ahead)
next=tween._prev;//record it here because the value could change after rendering...
if(curTime!==self._time||(self._paused&&!prevPaused)){//in case a tween pauses or seeks the timeline when rendering, like inside of an onUpdate/onComplete
pauseTween=tween._prev;//the linked list is organized by _startTime, thus it's possible that a tween could start BEFORE the pause and end after it, in which case it would be positioned before the pause tween in the linked list, but we should render it before we pause() the timeline and cease rendering. This is only a concern when going in reverse.
self._pauseTime=pauseTime;//so that when we resume(), it's starting from exactly the right spot (the pause() method uses the rawTime for the parent, but that may be a bit too far ahead)
if(_lazyTweens.length){//in case rendering caused any tweens to lazy-init, we should render them because typically when a timeline finishes, users expect things to have rendered fully. Imagine an onUpdate on a timeline that reports/checks tweened values.
_lazyRender();
}
self._callback("onUpdate");
}
if(callback)if(!self._gc)if(prevStart===self._startTime||prevTimeScale!==self._timeScale)if(self._time===0||totalDur>=self.totalDuration()){//if one of the tweens that was rendered altered this timeline's startTime (like if an onComplete reversed the timeline), it probably isn't complete. If it is, don't worry, because whatever call altered the startTime would complete if it was necessary at the new time. The only exception is the timeScale property. Also check _gc because there's a chance that kill() could be called in an onUpdate
if(isComplete){
if(_lazyTweens.length){//in case rendering caused any tweens to lazy-init, we should render them because typically when a timeline finishes, users expect things to have rendered fully. Imagine an onComplete on a timeline that reports/checks tweened values.
this._enabled(true,true);//getTweensOf() filters out disabled tweens, and we have to mark them as _gc = true when the timeline completes in order to allow clean garbage collection, so temporarily re-enable the timeline here.
prev=tween._prev;//record it here in case the tween changes position in the sequence...
if(tween._dirty){
tween.totalDuration();//could change the tween._startTime, so make sure the tween's cache is clean before analyzing it.
}
if(tween._startTime>prevStart&&self._sortChildren&&!tween._paused&&!self._calculatingDuration){//in case one of the tweens shifted out of order, it needs to be re-inserted into the correct position in the sequence
self._calculatingDuration=1;//prevent endless recursive calls - there are methods that get triggered that check duration/totalDuration when we add(), like _parseTimeOrLabel().
self.add(tween,tween._startTime-tween._delay);
self._calculatingDuration=0;
}else{
prevStart=tween._startTime;
}
if(tween._startTime<0&&!tween._paused){//children aren't allowed to have negative startTimes unless smoothChildTiming is true, so adjust here if one is found.
tween._rawPrevTime=0;//remember, _rawPrevTime is how zero-duration tweens/callbacks sense directionality and determine whether or not to fire. If _rawPrevTime is the same as _startTime on the next render, it won't fire.