var_gsScope=(typeof(module)!=="undefined"&&module.exports&&typeof(global)!=="undefined")?global:this||window;//helps ensure compatibility with AMD/RequireJS and CommonJS/Node
//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
_distribute=function(v){
if(typeof(v)==="function"){
returnv;
}
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.
self._timeline.insert(self,self._startTime-self._delay);//ensures that any necessary re-sequencing of Animations in the timeline occurs to make sure the rendering order is correct.
}
}
for(pinvars){
self.vars[p]=vars[p];
}
if(self._initted||immediate){
if(resetDuration){
self._initted=false;
if(immediate){
self.render(0,true,true);
}
}else{
if(self._gc){
self._enabled(true,false);
}
if(self._notifyPluginsOfEnabled&&self._firstPT){
TweenLite._onPluginEvent("_onDisable",self);//in case a plugin like MotionBlur must perform some cleanup tasks
}
if(self._time/self._duration>0.998){//if the tween has finished (or come extremely close to finishing), we just need to rewind it to 0 and then render it again at the end which forces it to re-initialize (parsing the new vars). We allow tweens that are close to finishing (but haven't quite finished) to work this way too because otherwise, the values are so small when determining where to project the starting values that binary math issues creep in and can make the tween appear to render incorrectly when run backwards.
varprevTime=self._totalTime;
self.render(0,true,false);
self._initted=false;
self.render(prevTime,true,false);
}else{
self._initted=false;
self._init();
if(self._time>0||immediate){
varinv=1/(1-curRatio),
pt=self._firstPT,endValue;
while(pt){
endValue=pt.s+pt.c;
pt.c*=inv;
pt.s=endValue-pt.c;
pt=pt._next;
}
}
}
}
}
returnself;
};
p.render=function(time,suppressEvents,force){
if(!this._initted)if(this._duration===0&&this.vars.repeat){//zero duration tweens that render immediately have render() called from TweenLite's constructor, before TweenMax's constructor has finished setting _repeat, _repeatDelay, and _yoyo which are critical in determining totalDuration() so we need to call invalidate() which is a low-kb way to get those set properly.
force=(force||self._timeline.autoRemoveChildren);//otherwise, if the animation is unpaused/activated after it's already finished, it doesn't get removed from the parent timeline.
}
if(duration===0)if(self._initted||!self.vars.lazy||force){//zero-duration tweens are tricky because we must discern the momentum/direction of time in order to determine whether the starting values should be rendered or the ending values. If the "playhead" of its timeline goes past the zero-duration tween in the forward direction or lands directly on it, the end values should be rendered, but if the timeline's "playhead" moves past it in the backward direction (from a postitive time to a negative time), the starting values must be rendered.
if(self._startTime===self._timeline._duration){//if a zero-duration tween is at the VERY end of a timeline and that timeline renders at its end, it will typically add a tiny bit of cushion to the render time to prevent rounding errors from getting in the way of tweens rendering their VERY end. If we then reverse() that timeline, the zero-duration tween will trigger its onReverseComplete even though technically the playhead didn't pass over it again. It's a very specific edge case we must accommodate.
time=0;
}
if(prevRawPrevTime<0||(time<=0&&time>=-_tinyNum)||(prevRawPrevTime===_tinyNum&&self.data!=="isPause"))if(prevRawPrevTime!==time){//note: when this.data is "isPause", it's a callback added by addPause() on a timeline that we should not be triggered when LEAVING its exact start time. In other words, tl.addPause(1).play(1) shouldn't pause.
force=true;
if(prevRawPrevTime>_tinyNum){
callback="onReverseComplete";
}
}
self._rawPrevTime=rawPrevTime=(!suppressEvents||time||prevRawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration 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.
}
}elseif(time<_tinyNum){//to work around occasional floating point math artifacts, round super small values to 0.
if(duration===0)if(self._initted||!self.vars.lazy||force){//zero-duration tweens are tricky because we must discern the momentum/direction of time in order to determine whether the starting values should be rendered or the ending values. If the "playhead" of its timeline goes past the zero-duration tween in the forward direction or lands directly on it, the end values should be rendered, but if the timeline's "playhead" moves past it in the backward direction (from a postitive time to a negative time), the starting values must be rendered.
if(prevRawPrevTime>=0){
force=true;
}
self._rawPrevTime=rawPrevTime=(!suppressEvents||time||prevRawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration 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._initted){//if we render the very beginning (time == 0) of a fromTo(), we must force the render (normal tweens wouldn't need to render at a time of 0 when the prevTime was also 0). This is also mandatory to make sure overwriting kicks in immediately.
force=true;
}
}else{
self._totalTime=self._time=time;
if(self._repeat!==0){
cycleDuration=duration+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 some browsers report it as 0.79999999!)
yoyoEase=self._yoyoEase||self.vars.yoyoEase;//note: we don't set this._yoyoEase in _init() like we do other properties because it's TweenMax-specific and doing it here allows us to optimize performance (most tweens don't have a yoyoEase). Note that we also must skip the this.ratio calculation further down right after we _init() in this function, because we're doing it here.
if(yoyoEase){
if(!self._yoyoEase){
if(yoyoEase===true&&!self._initted){//if it's not initted and yoyoEase is true, this._ease won't have been populated yet so we must discern it here.
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._callback("onUpdate");
}
return;
}elseif(!self._initted){
self._init();
if(!self._initted||self._gc){//immediateRender tweens typically won't initialize until the playhead advances (_time is greater than 0) in order to ensure that overwriting occurs properly. Also, if all of the tweening properties have been overwritten (which would cause _gc to be true, as set in _init()), we shouldn't continue otherwise an onStart callback could be called for example.
return;
}elseif(!force&&self._firstPT&&((self.vars.lazy!==false&&self._duration)||(self.vars.lazy&&!self._duration))){//we stick it in the queue for rendering at the very end of the tick - this is a performance optimization because browsers invalidate styles and force a recalculation if you read, write, and then read style data (so it's better to read/read/read/write/write/write than read/write/read/write/read/write). The down side, of course, is that usually you WANT things to render immediately because you may have code running right after that which depends on the change. Like imagine running TweenLite.set(...) and then immediately after that, creating a nother tween that animates the same property to another value; the starting values of that 2nd tween wouldn't be accurate if lazy is true.
self._time=prevTime;
self._totalTime=prevTotalTime;
self._rawPrevTime=prevRawPrevTime;
self._cycle=prevCycle;
TweenLiteInternals.lazyTweens.push(self);
self._lazy=[time,suppressEvents];
return;
}
//_ease is initially set to defaultEase, so now that init() has run, _ease is set properly and we need to recalculate the ratio. Overall this is faster than using conditional logic earlier in the method to avoid having to set ratio twice because we only init() once but renderTime() gets called VERY frequently.
self._active=true;//so that if the user renders a tween (as opposed to the timeline rendering it), the timeline is forced to re-render and align it with the proper time/frame on the next rendering cycle. Maybe the tween already finished but the user manually re-renders it as halfway done.
}
if(prevTotalTime===0){
if(self._initted===2&&time>0){
self._init();//will just apply overwriting since _initted of (2) means it was a from() tween that had immediateRender:true
}
if(self._startAt){
if(time>=0){
self._startAt.render(time,true,force);
}elseif(!callback){
callback="_dummyGS";//if no callback is defined, use a dummy value just so that the condition at the end evaluates as true because _startAt should render AFTER the normal render loop when the time is negative. We could handle this in a more intuitive way, of course, but the render loop is the MOST important thing to optimize, so this technique allows us to avoid adding extra conditional logic in a high-frequency area.
if(time<0)if(self._startAt&&self._startTime){//if the tween is positioned at the VERY beginning (_startTime 0) of its parent timeline, it's illegal for the playhead to go back further, so we should not render the recorded startAt values.
self._startAt.render(time,true,force);//note: for performance reasons, we tuck this conditional logic inside less traveled areas (most tweens don't have an onUpdate). We'd just have it at the end before the onComplete, but the values should be updated before any onUpdate is called, so we ALSO put it here and then if it's not called, we do so later near the onComplete.
if(callback)if(!self._gc||force){//check gc because there's a chance that kill() could be called in an onUpdate
if(time<0&&self._startAt&&!self._onUpdate&&self._startTime){//if the tween is positioned at the VERY beginning (_startTime 0) of its parent timeline, it's illegal for the playhead to go back further, so we should not render the recorded startAt values.
self._startAt.render(time,true,force);
}
if(isComplete){
if(self._timeline.autoRemoveChildren){
self._enabled(false,false);
}
self._active=false;
}
if(!suppressEvents&&self.vars[callback]){
self._callback(callback);
}
if(duration===0&&self._rawPrevTime===_tinyNum&&rawPrevTime!==_tinyNum){//the onComplete or onReverseComplete could trigger movement of the playhead and for zero-duration tweens (which must discern direction) that land directly back on their start time, we don't want to fire again on the next render. Think of several addPause()'s in a timeline that forces the playhead to a certain spot, but what if it's already paused and another tween is tweening the "time" of the timeline? Each time it moves [forward] past that spot, it would move back, and since suppressEvents is true, it'd reset _rawPrevTime to _tinyNum so that when it begins again, the callback would fire (so ultimately it could bounce back and forth during that tween). Again, this is a very uncommon scenario, but possible nonetheless.
returnthis._duration;//don't set _dirty = false because there could be repeats that haven't been factored into the _totalDuration yet. Otherwise, if you create a repeated TweenMax and then immediately check its duration(), it would cache the value and the totalDuration would not be correct, thus repeats wouldn't take effect.
_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
_distribute=function(v){
if(typeof(v)==="function"){
returnv;
}
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.
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.
seg.b=cp1=seg.a+(seg.c-seg.a)*0.6;//instead of placing b on a exactly, we move it inline with c so that if the user specifies an ease like Back.easeIn or Elastic.easeIn which goes BEYOND the beginning, it will do so smoothly.
}
seg.da=p2-p1;
seg.ca=cp2-p1;
seg.ba=cp1-p1;
if(quad){
qb=cubicToQuadratic(p1,cp1,cp2,p2);
a.splice(ii,1,qb[0],qb[1],qb[2],qb[3]);
ii+=4;
}else{
ii++;
}
cp1=m2;
}
seg=a[ii];
seg.b=cp1;
seg.c=cp1+(seg.d-cp1)*0.4;//instead of placing c on d exactly, we move it inline with b so that if the user specifies an ease like Back.easeOut or Elastic.easeOut which goes BEYOND the end, it will do so smoothly.
values[i][p]=prepend[p]+Number(tmp.charAt(0)+tmp.substr(2));//accommodate relative values. Do it inline instead of breaking it out into a function for speed reasons
//check to see if the last and first values are identical (well, within 0.05). If so, make seamless by appending the second element to the very end of the values array and the 2nd-to-last element to the very beginning (we'll remove those segments later)
if(values.length>1){
last=values[values.length-1];
seamless=true;
i=props.length;
while(--i>-1){
p=props[i];
if(Math.abs(first[p]-last[p])>0.05){//build in a tolerance of +/-0.05 to accommodate rounding errors.
seamless=false;
break;
}
}
if(seamless){
values=values.concat();//duplicate the array to avoid contaminating the original which the user may be reusing for other tweens
_calculateControlPoints(a,curviness,quadratic,basic,_corProps[p]);//this method requires that _parseAnchors() and _setSegmentRatios() ran first so that _r1, _r2, and _r3 values are populated for all properties
this._startRatio=tween.vars.runBackwards?1:0;//we determine the starting ratio when the tween inits which is always 0 unless the tween has runBackwards:true (indicating it's a from() tween) in which case it's 1.
returntrue;
},
//called each time the values should be updated, and the ratio gets passed as the only parameter (typically it's a value between 0 and 1, but it can exceed those when using an ease like Elastic.easeOut or Back.easeOut, etc.)
v[p]=e[p];//duplicate the vars object because we need to alter some things which would cause problems if the user plans to reuse the same vars object for another tween.
this.setRatio=CSSPlugin.prototype.setRatio;//speed optimization (avoid prototype lookup on this "hot" method)
},
_globals=_gsScope._gsDefine.globals,
_hasPriority,//turns true whenever a CSSPropTween instance is created that has a priority other than 0. This helps us discern whether or not we should spend the time organizing the linked list or not after a CSSPlugin's _onInitTween() method is called.
_suffixMap,//we set this in _onInitTween() each time as a way to have a persistent variable we can use in other methods like _parse() without having to pass it around as a parameter and we keep _parse() decoupled from a particular CSSPlugin instance
_cs,//computed style (we store this in a shared variable to conserve memory and make minification tighter
_overwriteProps,//alias to the currently instantiating CSSPlugin's _overwriteProps array. We use this closure in order to avoid having to pass a reference around from method to method and aid in minification.
_specialProps={},
p=CSSPlugin.prototype=newTweenPlugin("css");
p.constructor=CSSPlugin;
CSSPlugin.version="2.1.3";
CSSPlugin.API=2;
CSSPlugin.defaultTransformPerspective=0;
CSSPlugin.defaultSkewType="compensated";
CSSPlugin.defaultSmoothOrigin=true;
p="px";//we'll reuse the "p" variable to keep file size down
_valuesExp=/(?:\+=|\-=|\-|\b)[\d\-\.]+[a-zA-Z0-9]*(?:%|\b)/gi,//finds all the values that begin with numbers or += or -= and then a number. Includes suffixes. We use this to split complex values apart like "1px 5px 20px rgb(255,102,51)"
_valuesExpWithCommas=/(?:\+=|\-=|\-|\b)[\d\-\.]+[a-zA-Z0-9]*(?:%|\b),?/gi,//finds all the values that begin with numbers or += or -= and then a number. Includes suffixes. We use this to split complex values apart like "1px 5px 20px rgb(255,102,51)"
_NaNExp=/(?![+-]?\d*\.?\d+|[+-]|e[+-]\d+)[^0-9]/g,//also allows scientific notation and doesn't kill the leading -/+ in -= and +=
_suffixExp=/(?:\d|\-|\+|=|#|\.)*/g,
_opacityExp=/opacity *= *([^)]*)/i,
_opacityValExp=/opacity:([^;]*)/i,
_alphaFilterExp=/alpha\(opacity *=.+?\)/i,
_rgbhslExp=/^(rgb|hsl)/,
_capsExp=/([A-Z])/g,
_camelExp=/-([a-z])/gi,
_urlExp=/(^(?:url\(\"|url\())|(?:(\"\))$|\)$)/gi,//for pulling out urls from url(...) or url("...") strings (some browsers wrap urls in quotes, some don't when reporting things like backgroundImage)
returne.style?e:_doc.createElement(type);//some environments won't allow access to the element's style when created with a namespace in which case we default to the standard createElement() to work around the issue. Also note that when GSAP is embedded directly inside an SVG file, createElement() won't allow access to the style object in Firefox (see https://greensock.com/forums/topic/20215-problem-using-tweenmax-in-standalone-self-containing-svg-file-err-cannot-set-property-csstext-of-undefined/).
},
_tempDiv=_createElement("div"),
_tempImg=_createElement("img"),
_internals=CSSPlugin._internals={_specialProps:_specialProps},//provides a hook to a few internal methods that we need to access from inside other plugins
_agent=(_gsScope.navigator||{}).userAgent||"",
_autoRound,
_reqSafariFix,//we won't apply the Safari transform fix until we actually come across a tween that affects a transform property (to maintain best performance).
_isSafari,
_isFirefox,//Firefox has a bug that causes 3D transformed elements to randomly disappear unless a repaint is forced after each update on each element.
_isSafariLT6,//Safari (and Android 4 which uses a flavor of Safari) has a bug that prevents changes to "top" and "left" properties from rendering properly if changed on the same frame as a transform UNLESS we set the element's WebkitBackfaceVisibility to hidden (weird, I know). Doing this for Android 3 and earlier seems to actually cause other problems, though (fun!)
_ieVers,
_supportsOpacity=(function(){//we set _isSafari, _ieVers, _isFirefox, and _supportsOpacity all in one function here to reduce file size slightly, especially in the minified version.
_log=function(s){//for logging messages, but in a way that won't throw errors in old versions of IE.
if(_gsScope.console){
console.log(s);
}
},
_target,//when initting a CSSPlugin, we set this variable so that we can access it from within many other functions without having to pass it around as params
_index,//when initting a CSSPlugin, we set this variable so that we can access it from within many other functions without having to pass it around as params
_prefixCSS="",//the non-camelCase vendor prefix like "-o-", "-moz-", "-ms-", or "-webkit-"
_prefix="",//camelCase vendor prefix like "O", "ms", "Webkit", or "Moz".
// @private feed in a camelCase property name like "transform" and it will check to see if it is valid as-is or if it needs a vendor prefix. It returns the corrected camelCase property name (i.e. "WebkitTransform" or "MozTransform" or "transform" or null if no such property is found, like if the browser is IE8 or before, "transform" won't be found at all)
return_computedStyleScope.getComputedStyle(e);//to avoid errors in Microsoft Edge, we need to call getComputedStyle() from a specific scope, typically window.
if(!_supportsOpacity)if(p==="opacity"){//several versions of IE don't use the standard "opacity" property - they use things like filter:alpha(opacity=50), so we parse that here.
if(p==="lineHeight"&&!sfx){//special case of when a simple lineHeight (without a unit) is used. Set it to the value, read back the computed value, and then revert.
if(_getStyle(node,"display").indexOf("flex")!==-1){//Edge and IE11 have a bug that causes offsetWidth to report as 0 if the container has display:flex and the child is position:relative. Switching to position: absolute solves it.
style.position="absolute";
}
cache=node._gsCache;
time=TweenLite.ticker.frame;
if(cache&&horiz&&cache.time===time){//performance optimization: we record the width of elements along with the ticker frame so that we can quickly get it again on the same tick (seems relatively safe to assume it wouldn't change on the same tick)
_calculateOffset=_internals.calculateOffset=function(t,p,cs){//for figuring out "top" or "left" in px when it's "auto". We need to factor in margin with the offsetLeft/offsetTop
// @private returns at object containing ALL of the style properties in camelCase and their associated values.
_getAllStyles=function(t,cs){
vars={},
i,tr,p;
if((cs=cs||_getComputedStyle(t,null))){
if((i=cs.length)){
while(--i>-1){
p=cs[i];
if(p.indexOf("-transform")===-1||_transformPropCSS===p){//Some webkit browsers duplicate transform values, one non-prefixed and one prefixed ("transform" and "WebkitTransform"), so we must weed out the extra one here.
}else{//some browsers behave differently - cs.length is always 0, so we must do a for...in loop.
for(iincs){
if(i.indexOf("Transform")===-1||_transformProp===i){//Some webkit browsers duplicate transform values, one non-prefixed and one prefixed ("transform" and "WebkitTransform"), so we must weed out the extra one here.
s[i]=cs[i];
}
}
}
}elseif((cs=t.currentStyle||t.style)){
for(iincs){
if(typeof(i)==="string"&&s[i]===undefined){
s[i.replace(_camelExp,_camelFunc)]=cs[i];
}
}
}
if(!_supportsOpacity){
s.opacity=_getIEOpacity(t);
}
tr=_getTransform(t,cs,false);
s.rotation=tr.rotation;
s.skewX=tr.skewX;
s.scaleX=tr.scaleX;
s.scaleY=tr.scaleY;
s.x=tr.x;
s.y=tr.y;
if(_supports3D){
s.z=tr.z;
s.rotationX=tr.rotationX;
s.rotationY=tr.rotationY;
s.scaleZ=tr.scaleZ;
}
if(s.filters){
deletes.filters;
}
returns;
},
// @private analyzes two style objects (as returned by _getAllStyles()) and only looks for differences between them that contain tweenable values (like a number or color). It returns an object with a "difs" property which refers to an object containing only those isolated properties and values for tweening, and a "firstMPT" property which refers to the first MiniPropTween instance in a linked list that recorded all the starting values of the different properties so that we can revert to them at the end or beginning of the tween - we don't want the cascading to get messed up. The forceLookup parameter is an optional generic object with properties that should be forced into the results - this is necessary for className tweens that are overwriting others because imagine a scenario where a rollover/rollout adds/removes a class and the user swipes the mouse over the target SUPER fast, thus nothing actually changed yet and the subsequent comparison of the properties would indicate they match (especially when px rounding is taken into consideration), thus no tweening is necessary even though it SHOULD tween and remove those properties after the tween (otherwise the inline styles will contaminate things). See the className SpecialProp code for details.
difs[p]=(val==="auto"&&(p==="left"||p==="top"))?_calculateOffset(t,p):((val===""||val==="auto"||val==="none")&&typeof(s1[p])==="string"&&s1[p].replace(_NaNExp,"")!=="")?0:val;//if the ending value is defaulting ("" or "auto"), we check the starting value and if it can be parsed into a number (a string which could have a suffix too, like 700px), then we swap in 0 for "" or "auto" so that things actually tween.
if(style[p]!==undefined){//for className tweens, we must remember which properties already existed inline - the ones that didn't should be removed when the tween isn't in progress because they were only introduced to facilitate the transition between classes.
// @private Parses position-related complex strings like "top left" or "50px 10px" or "70% 20%", etc. which are used for things like transformOrigin or backgroundPosition. Optionally decorates a supplied object (recObj) with the following properties: "ox" (offsetX), "oy" (offsetY), "oxp" (if true, "ox" is a percentage not a pixel value), and "oxy" (if true, "oy" is a percentage not a pixel value)
if(x==="center"||(isNaN(parseFloat(x))&&(x+"").indexOf("=")===-1)){//remember, the user could flip-flop the values and say "bottom center" or "center bottom", etc. "center" is ambiguous because it could be used to describe horizontal or vertical, hence the isNaN(). If there's an "=" sign in the value, it's relative.
*@privateTranslatesstringslike"40deg"or"40"or40rad" or "+=40deg" or "270_short" or "-90_cw" or "+=45_ccw"toanumericradianangle.Ofcourseastarting/defaultvaluemustbefedintoosothatrelativevaluescanbecalculatedproperly.
if(v.charAt(v.length-1)===","){//sometimes a trailing comma is included and we should chop it off (typically from a comma-delimited list of values like a textShadow:"2px 2px 2px blue, 5px 5px 5px rgb(255,0,0)" - in this example "blue," has a trailing comma. We could strip it out inside parseComplex() but we'd need to do it to the beginning and ending values plus it wouldn't provide protection from other potential scenarios like if the user passes in a similar value.
v=v.substr(0,v.length-1);
}
if(_colorLookup[v]){
a=_colorLookup[v];
}elseif(v.charAt(0)==="#"){
if(v.length===4){//for shorthand like #9F0
r=v.charAt(1);
g=v.charAt(2);
b=v.charAt(3);
v="#"+r+r+g+g+b+b;
}
v=parseInt(v.substr(1),16);
a=[v>>16,(v>>8)&255,v&255];
}elseif(v.substr(0,3)==="hsl"){
a=wasHSL=v.match(_numExp);
if(!toHSL){
h=(Number(a[0])%360)/360;
s=Number(a[1])/100;
l=Number(a[2])/100;
g=(l<=0.5)?l*(s+1):l+s-l*s;
r=l*2-g;
if(a.length>3){
a[3]=Number(a[3]);
}
a[0]=_hue(h+1/3,r,g);
a[1]=_hue(h,r,g);
a[2]=_hue(h-1/3,r,g);
}elseif(v.indexOf("=")!==-1){//if relative values are found, just return the raw strings with the relative prefixes in place.
_colorExp="(?:\\b(?:(?:rgb|rgba|hsl|hsla)\\(.+?\\))|\\B#(?:[0-9a-f]{3}){1,2}\\b";//we'll dynamically build this Regular Expression to conserve file size. After building it, it will be able to find rgb(), rgba(), # (hexadecimal), and named color values like red, blue, purple, etc.
return((pfx&&v!=="none")?v.substr(0,v.indexOf(vals[0]))||pfx:pfx)+vals.join(delim)+sfx;//note: prefix might be different, like for clipPath it could start with inset( or polygon(
// @private used when other plugins must tween values first, like BezierPlugin or ThrowPropsPlugin, etc. That plugin's setRatio() gets called first so that the values are updated, and then we loop through the MiniPropTweens which handle copying the values into their appropriate slots so that they can then be applied correctly in the main CSSPlugin setRatio() method. Remember, we typically create a proxy object that has a bunch of uniquely-named properties that we feed to the sub-plugin and it does its magic normally, and then we must interpret those values and apply them to the css because often numbers must get combined/concatenated, suffixes added, etc. to work with css, like boxShadow could have 4 values plus a color.
d.autoRotate.rotation=d.mod?d.mod.call(this._tween,proxy.rotation,this.t,this._tween):proxy.rotation;//special case for ModifyPlugin to hook into an auto-rotating bezier
}
//at the end, we must set the CSSPropTween's "e" (end) value dynamically here because that's what is used in the final setRatio() method. Same for "b" at the beginning.
*@privateMostotherplugins(likeBezierPluginandThrowPropsPluginandothers)canonlytweennumericvalues,butCSSPluginmustaccommodatespecialvaluesthathaveabunchofextradata(likeasuffixorstringsbetweennumericvalues,etc.).Forexample,boxShadowhasvalueslike"10px 10px 20px 30px rgb(255,0,0)"whichwouldutterlyconfuseotherplugins.Thismethodallowsustosplitthatdataapartandgrabonlythenumericdataandattachittouniquely-namedpropertiesofagenericproxyobject({})sothatwecanfeedthattovirtuallyanyplugintohavethenumberstweened.However,wemustalsokeeptrackofwhichpropertiesfromtheproxygowithwhichCSSPropTweenvaluesandinstances.SowecreatealinkedlistofMiniPropTweens.Eachonerecordsatarget(theoriginalCSSPropTween),property(like"s"or"xn1"or"xn2")thatwe're tweening and the unique property name that was used for the proxy (like "boxShadow_xn1" and "boxShadow_xn2") and whether or not they need to be rounded. That way, in the _setPluginRatio() method we can simply copy the values over from the proxy to the CSSPropTween instance(s). Then, when the main CSSPlugin setRatio() method runs and applies the CSSPropTween values accordingly, they'reupdatednicely.Sotheexternalplugintweensthenumbers,_setPluginRatio()copiesthemover,andsetRatio()actsnormally,applyingcss-specificvaluestotheelement.
*-xfirst:Thefirstinstanceofanysub-CSSPropTweensthataretweeningpropertiesofthisinstance.Forexample,wemaysplitupaboxShadowtweensothatthere's a main CSSPropTween of type:1 that has various xs* and xn* values associated with the h-shadow, v-shadow, blur, color, etc. Then we spawn a CSSPropTween for each of those that has a higher priority and runs BEFORE the main CSSPropTween so that the values are all set by the time it needs to re-assemble them. The xfirst gives us an easy way to identify the first one in that chain which typically ends at the main one (because they'reallprependetothelinkedlist)
*-data:ArbitrarydatathatneedstobestoredwiththeCSSPropTween.Typicallyifwe're going to have a plugin handle the tweening of a complex-value tween, we create a generic object that stores the END values that we'retweeningtoandtheCSSPropTween'sxs1,xs2,etc.havethestartingvalues.Westorethatobjectasdata.Thatway,wecansimplypassthatobjecttothepluginandusetheCSSPropTweenasthetarget.
*-setRatio:Onlyusedfortype:2tweensthatrequirecustomfunctionality.Inthiscase,wecalltheCSSPropTween's setRatio() method and pass the ratio each time the tween updates. This isn'tquiteasefficientasdoingthingsdirectlyintheCSSPlugin's setRatio() method, but it'sveryconvenientandflexible.
this.type=type||0;//0 = normal tween, -1 = non-tweening (in which case xs0 will be applied to the target's property, like tp.t[tp.p] = tp.xs0), 1 = complex-value SpecialProp, 2 = custom setRatio() that does all the work
if(pr){
this.pr=pr;
_hasPriority=true;
}
this.b=(b===undefined)?s:b;
this.e=(e===undefined)?s+c:e;
if(next){
this._next=next;
next._prev=this;
}
},
_addNonTweeningNumericPT=function(target,prop,start,end,next,overwriteProp){//cleans up some code redundancies and helps minification. Just a fast way to add a NUMERIC non-tweening CSSPropTween
*sp.parseComplex(element,"boxShadow","5px 10px 20px rgb(255,102,51)","0px 0px 0px red",true,"0px 0px 0px rgb(0,0,0,0)",pt);
*Itwillwalkthroughthebeginningandendingvalues(whichshouldbeinthesameformatwiththesamenumberandtypeofvalues)andfigureoutwhichpartsarenumbers,whatstringsseparatethenumeric/tweenablevalues,andthencreatetheCSSPropTweensaccordingly.Ifapluginisdefined,nochildCSSPropTweenswillbecreated.Instead,theendingvalueswillbestoredinthe"data"propertyofthereturnedCSSPropTweenlike:{s:-5,xn1:-10,xn2:-20,xn3:255,xn4:0,xn5:0}sothatitcanbefedtoanyotherpluginandit'll be plain numeric tweens but the recomposition of the complex value will be handled inside CSSPlugin'ssetRatio().
temp=ev;//original string value so we can look for any prefix later.
bv=_parseColor(bv,useHSL);
ev=_parseColor(ev,useHSL);
hasAlpha=(bv.length+ev.length>6);
if(hasAlpha&&!_supportsOpacity&&ev[3]===0){//older versions of IE don't support rgba(), so if the destination alpha is 0, just use "transparent" for the end color
pt["xs"+pt.l]+=pt.l?" transparent":"transparent";
pt.e=pt.e.split(ea[i]).join("transparent");
}else{
if(!_supportsOpacity){//old versions of IE don't support rgba().
_colorExp.lastIndex=0;//otherwise the test() on the RegExp could move the lastIndex and taint future results.
}else{
bnums=bv.match(_numExp);//gets each group of numbers in the beginning value string and drops them into an array
//if no number is found, treat it as a non-tweening value and just append the string to the current xs.
if(!bnums){
pt["xs"+pt.l]+=(pt.l||pt["xs"+pt.l])?" "+ev:ev;
//loop through all the numbers that are found and construct the extra values on the pt.
}else{
enums=ev.match(_relNumExp);//get each group of numbers in the end value string and drop them into an array. We allow relative values too, like +=50 or -=.5
if(!enums||enums.length!==bnums.length){
//DEBUG: _log("mismatched formatting detected on " + p + " (" + b + " vs " + e + ")");
if(!c)if(l!==0&&!pt.plugin){//typically we'll combine non-changing values right into the xs to optimize performance, but we don't combine them when there's a plugin that will be tweening the values because it may depend on the values being split apart, like for a bezier, if a value doesn't change between the first and second iteration but then it does on the 3rd, we'll run into trouble because there's no xn slot for that value!
pt["xs"+l]+=s+(sfx||"");
returnpt;
}
pt.l++;
pt.type=pt.setRatio?2:1;
pt["xs"+pt.l]=sfx||"";
if(l>0){
pt.data["xn"+l]=s+c;
pt.rxp["xn"+l]=r;//round extra property (we need to tap into this in the _parseToProxy() method)
pt.xfirst.xs0=0;//just to ensure that the property stays numeric which helps modern browsers speed up processing. Remember, in the setRatio() method, we do pt.t[pt.p] = val + pt.xs0 so if pt.xs0 is "" (the default), it'll cast the end value as a string. When a property is a number sometimes and a string sometimes, it prevents the compiler from locking in the data type, slowing things down slightly.
//shortcut for creating a new SpecialProp that can accept multiple properties as a comma-delimited list (helps minification). dflt can be an array for multiple values (we don't do a comma-delimited list because the default value may contain commas, like rect(0px,0px,0px,0px)). We attach this method to the SpecialProp class/object instead of using a private _createSpecialProp() method so that we can tap into it externally if necessary, like from another plugin.
options={parser:defaults};//to make backwards compatible with older versions of BezierPlugin and ThrowPropsPlugin
}
vara=p.split(","),
d=options.defaultValue,
i,temp;
defaults=defaults||[d];
for(i=0;i<a.length;i++){
options.prefix=(i===0&&options.prefix);
options.defaultValue=defaults[i]||d;
temp=newSpecialProp(a[i],options);
}
},
//creates a placeholder special prop for a plugin so that the property gets caught the first time a tween of it is attempted, and at that time it makes the plugin register itself, thus taking over for all future tweens of that property. This allows us to not mandate that things load in a particular order and it also allows us to log() an error that informs the user when they attempt to tween an external plugin-related property without loading its .js file.
//if this SpecialProp's value can contain a comma-delimited list of values (like boxShadow or textShadow), we must parse them in a special way, and look for a keyword (like "inset" for boxShadow) and ensure that the beginning and ending BOTH have it if the end defines it as such. We also must ensure that there are an equal number of values specified (we can't tween 1 boxShadow to 3 for example)
CSSPlugin.useSVGTransformAttr=true;//Safari and Firefox both have some rendering bugs when applying CSS transforms to SVG elements, so default to using the "transform" attribute instead (users can override this).
//Some browsers (like Firefox and IE) don't honor transform-origin properly in SVG elements, so we need to manually adjust the matrix accordingly. We feature detect here rather than always doing the conversion for certain browsers because they may fix the problem at some point in the future.
//IE and Android stock don't support CSS transforms on SVG elements, so we must write them to the "transform" attribute. We populate this variable in the _parseTransform() method, and only if/when we come across an SVG element
force=(width===rect.getBoundingClientRect().width&&!(_isFirefox&&_supports3D));//note: Firefox fails the test even though it does support CSS transforms in 3D. Since we can't push 3D stuff into the transform attribute, we force Firefox to pass the test here (as long as it does truly support 3D).
xOriginOld=tm.xOrigin;//record the original values before we alter them.
yOriginOld=tm.yOrigin;
}
if(!absolute||(v=absolute.split(" ")).length<2){
b=e.getBBox();
if(b.x===0&&b.y===0&&b.width+b.height===0){//some browsers (like Firefox) misreport the bounds if the element has zero width and height (it just assumes it's at x:0, y:0), thus we need to manually grab the position in that case.
if(absolute&&m!==_identity2DMatrix){//if svgOrigin is being set, we must invert the matrix and determine where the absolute point is, factoring in the current transforms. Otherwise, the svgOrigin would be based on the element's non-transformed position on the canvas.
a=m[0];
b=m[1];
c=m[2];
d=m[3];
tx=m[4];
ty=m[5];
determinant=(a*d-b*c);
if(determinant){//if it's zero (like if scaleX and scaleY are zero), skip it to avoid errors with dividing by zero.
//originally, we simply adjusted the x and y values, but that would cause problems if, for example, you created a rotational tween part-way through an x/y tween. Managing the offset in a separate variable gives us ultimate flexibility.
//tm.x -= x - (x * m[0] + y * m[2]);
//tm.y -= y - (x * m[1] + y * m[3]);
tm.xOffset+=(x*m[0]+y*m[2])-x;
tm.yOffset+=(x*m[1]+y*m[3])-y;
}else{
tm.xOffset=tm.yOffset=0;
}
}
if(!skipRecord){
e.setAttribute("data-svg-origin",v.join(" "));
}
},
_getBBoxHack=function(swapIfPossible){//works around issues in some browsers (like Firefox) that don't correctly report getBBox() on SVG elements inside a <defs> element and/or <mask>. We try creating an SVG, adding it to the documentElement and toss the element in there so that it's definitely part of the rendering tree, then grab the bbox and if it works, we actually swap out the original getBBox() method for our own that does these extra steps whenever getBBox is needed. This helps ensure that performance is optimal (only do all these extra steps when absolutely necessary...most elements don't need it).
returne.getBBox();//Firefox throws errors if you try calling getBBox() on an SVG element that's not rendered (like in a <symbol> or <defs>). https://bugzilla.mozilla.org/show_bug.cgi?id=612118
}catch(error){
return_getBBoxHack.call(e,true);
}
},
_isSVG=function(e){//reports if the element is an SVG on which getBBox() actually works
//for older versions of IE, we need to interpret the filter portion that is in the format: progid:DXImageTransform.Microsoft.Matrix(M11=6.123233995736766e-17, M12=-1, M21=1, M22=6.123233995736766e-17, sizingMethod='auto expand') Notice that we need to swap b and c compared to a normal matrix.
if(_transformProp&&isDefault&&!e.offsetParent&&e!==_docElement){//note: if offsetParent is null, that means the element isn't in the normal document flow, like if it has display:none or one of its ancestors has display:none). Firefox returns null for getComputedStyle() if the element is in an iframe that has display:none. https://bugzilla.mozilla.org/show_bug.cgi?id=548397
//browsers don't report transforms accurately unless the element is in the DOM and has a display value that's not "none". Firefox and Microsoft browsers have a partial bug where they'll report transforms even if display:none BUT not any percentage-based values like translate(-50%, 8px) will be reported as if it's translate(0, 8px).
n=style.display;
style.display="block";
parent=e.parentNode;
if(!parent||!e.offsetParent){
dec=1;//flag
nextSibling=e.nextSibling;
_docElement.appendChild(e);//we must add it to the DOM in order to get values properly
if(isDefault&&(style[_transformProp]+"").indexOf("matrix")!==-1){//some browsers (like Chrome 40) don't correctly report transforms that are applied inline on an SVG element (they don't get included in the computed style), so we double-check here and accept matrix values
s=style[_transformProp];
isDefault=0;
}
m=e.getAttribute("transform");
if(isDefault&&m){
m=e.transform.baseVal.consolidate().matrix;//ensures that even complex values like "translate(50,60) rotate(135,0,0)" are parsed because it mashes it into a matrix.
//split the matrix values out into an array (m for matrix)
m=(s||"").match(_numExp)||[];
i=m.length;
while(--i>-1){
n=Number(m[i]);
m[i]=(dec=n-(n|=0))?((dec*rnd+(dec<0?-0.5:0.5))|0)/rnd+n:n;//convert strings to Numbers and round to 5 decimal places to avoid issues with tiny numbers. Roughly 20x faster than Number.toFixed(). We also must make sure to round before dividing so that values like 0.9999999999 become 1 to avoid glitches in browser rendering and interpretation of flipped/rotated 3D matrices. And don't just multiply the number by rnd, floor it, and then divide by rnd because the bitwise operations max out at a 32-bit signed integer, thus it could get clipped at a relatively low value (like 22,000.00000 for example).
returnt._gsTransform;//if the element already has a _gsTransform, use that. Note: some browsers don't accurately return the calculated style for the transform (particularly for SVG), so it's almost always safest to just use the values we've already applied rather than re-parsing things.
invX=(tm.scaleX<0),//in order to interpret things properly, we need to know if the user applied a negative scaleX previously so that we can adjust the rotation and skewX accordingly. Otherwise, if we always interpret a flipped matrix as affecting scaleY and the user only wants to tween the scaleX on multiple sequential tweens, it would keep the negative scaleY without that being the user's intent.
//we'll only look at these position-related 6 variables first because if x/y/z all match, it's relatively safe to assume we don't need to re-parse everything which risks losing important rotational information (like rotationX:180 plus rotationY:180 would look the same as rotation:180 - there's no way to know for sure which direction was taken based solely on the matrix3d() values)
vara11=m[0],a21=m[1],a31=m[2],a41=m[3],
a12=m[4],a22=m[5],a32=m[6],a42=m[7],
a13=m[8],a23=m[9],a33=m[10],
a14=m[12],a24=m[13],a34=m[14],
a43=m[11],
angle=Math.atan2(a32,a33),
t1,t2,t3,t4,cos,sin;
//we manually compensate for non-zero z component of transformOrigin to work around bugs in Safari
if(tm.zOrigin){
a34=-tm.zOrigin;
a14=a13*a34-m[12];
a24=a23*a34-m[13];
a34=a33*a34+tm.zOrigin-m[14];
}
//note for possible future consolidation: rotationX: Math.atan2(a32, a33), rotationY: Math.atan2(-a31, Math.sqrt(a33 * a33 + a32 * a32)), rotation: Math.atan2(a21, a11), skew: Math.atan2(a12, a22). However, it doesn't seem to be quite as reliable as the full-on backwards rotation procedure.
tm.rotationX=angle*_RAD2DEG;
//rotationX
if(angle){
cos=Math.cos(-angle);
sin=Math.sin(-angle);
t1=a12*cos+a13*sin;
t2=a22*cos+a23*sin;
t3=a32*cos+a33*sin;
a13=a12*-sin+a13*cos;
a23=a22*-sin+a23*cos;
a33=a32*-sin+a33*cos;
a43=a42*-sin+a43*cos;
a12=t1;
a22=t2;
a32=t3;
}
//rotationY
angle=Math.atan2(-a31,a33);
tm.rotationY=angle*_RAD2DEG;
if(angle){
cos=Math.cos(-angle);
sin=Math.sin(-angle);
t1=a11*cos-a13*sin;
t2=a21*cos-a23*sin;
t3=a31*cos-a33*sin;
a23=a21*sin+a23*cos;
a33=a31*sin+a33*cos;
a43=a41*sin+a43*cos;
a11=t1;
a21=t2;
a31=t3;
}
//rotationZ
angle=Math.atan2(a21,a11);
tm.rotation=angle*_RAD2DEG;
if(angle){
cos=Math.cos(angle);
sin=Math.sin(angle);
t1=a11*cos+a21*sin;
t2=a12*cos+a22*sin;
t3=a13*cos+a23*sin;
a21=a21*cos-a11*sin;
a22=a22*cos-a12*sin;
a23=a23*cos-a13*sin;
a11=t1;
a12=t2;
a13=t3;
}
if(tm.rotationX&&Math.abs(tm.rotationX)+Math.abs(tm.rotation)>359.9){//when rotationY is set, it will often be parsed as 180 degrees different than it should be, and rotationX and rotation both being 180 (it looks the same), so we adjust for that here.
tm.scaleY*=1/Math.cos(angle);//by default, we compensate the scale based on the skew so that the element maintains a similar proportion when skewed, so we have to alter the scaleY here accordingly to match the default (non-adjusted) skewing that CSS does (stretching more and more as it skews).
}elseif((!_supports3D||parse||!m.length||tm.x!==m[4]||tm.y!==m[5]||(!tm.rotationX&&!tm.rotationY))){//sometimes a 6-element matrix is returned even when we performed 3D transforms, like if rotationX and rotationY are 180. In cases like this, we still need to honor the 3D transforms. If we just rely on the 2D info, it could affect how the data is interpreted, like scaleY might get set to -1 or rotation could get offset by 180 degrees. For example, do a TweenLite.to(element, 1, {css:{rotationX:180, rotationY:180}}) and then later, TweenLite.to(element, 1, {css:{rotationX:0}}) and without this conditional logic in place, it'd jump to a state of being unrotated when the 2nd tween starts. Then again, we need to honor the fact that the user COULD alter the transforms outside of CSSPlugin, like by manually applying new css, so we try to sense that by looking at x and y because if those changed, we know the changes were made outside CSSPlugin and we force a reinterpretation of the matrix values. Also, in Webkit browsers, if the element's "display" is "none", its calculated style value will always return empty, so if we've already recorded the values in the _gsTransform object, we'll just rely on those.
vark=(m.length>=6),
a=k?m[0]:1,
b=m[1]||0,
c=m[2]||0,
d=k?m[3]:1;
tm.x=m[4]||0;
tm.y=m[5]||0;
scaleX=Math.sqrt(a*a+b*b);
scaleY=Math.sqrt(d*d+c*c);
rotation=(a||b)?Math.atan2(b,a)*_RAD2DEG:tm.rotation||0;//note: if scaleX is 0, we cannot accurately measure rotation. Same for skewX with a scaleY of 0. Therefore, we default to the previously recorded value (or zero if that doesn't exist).
//some browsers have a hard time with very small values like 2.4492935982947064e-16 (notice the "e-" towards the end) and would render the object slightly off. So we round to 0 in these cases. The conditional logic here is faster than calling Math.abs(). Also, browsers tend to render a SLIGHTLY rotated object in a fuzzy way, so we need to snap to exactly 0 when appropriate.
t._gsTransform=tm;//record to the object's _gsTransform which we use so that tweens can control individual properties independently (we need all the properties to accurately recompose the matrix in the setRatio() method)
if(tm.svg){//if we're supposed to apply transforms to the SVG element's "transform" attribute, make sure there aren't any CSS transforms applied or they'll override the attribute ones. Also clear the transform attribute if we're using CSS, just to be clean.
TweenLite.delayedCall(0.001,function(){//if we apply this right away (before anything has rendered), we risk there being no transforms for a brief moment and it also interferes with adjusting the transformOrigin in a tween with immediateRender:true (it'd try reading the matrix and it wouldn't have the appropriate data in place because we just removed it).
//for setting 2D transforms in IE6, IE7, and IE8 (must use a "filter" to emulate the behavior of modern day browser transforms)
_setIETransformRatio=function(v){
vart=this.data,//refers to the element's _gsTransform object
ang=-t.rotation*_DEG2RAD,
skew=ang+t.skewX*_DEG2RAD,
rnd=100000,
a=((Math.cos(ang)*t.scaleX*rnd)|0)/rnd,
b=((Math.sin(ang)*t.scaleX*rnd)|0)/rnd,
c=((Math.sin(skew)*-t.scaleY*rnd)|0)/rnd,
d=((Math.cos(skew)*t.scaleY*rnd)|0)/rnd,
style=this.t.style,
cs=this.t.currentStyle,
filters,val;
if(!cs){
return;
}
val=b;//just for swapping the variables an inverting them (reused "val" to avoid creating another variable in memory). IE's filter matrix uses a non-standard matrix configuration (angle goes the opposite way, and b and c are reversed and inverted)
b=-c;
c=-val;
filters=cs.filter;
style.filter="";//remove filters so that we can accurately measure offsetWidth/offsetHeight
style.filter=m+" "+filters;//we must always put the transform/matrix FIRST (before alpha(opacity=xx)) to avoid an IE bug that slices part of the object when rotation is applied with alpha.
}
//at the end or beginning of the tween, if the matrix is normal (1, 0, 0, 1) and opacity is 100 (or doesn't exist), remove the filter to improve browser performance.
//we must set the margins AFTER applying the filter in order to avoid some bugs in IE8 that could (in rare scenarios) cause them to be ignored intermittently (vibration).
if(!clip){
varmult=(_ieVers<8)?1:-1,//in Internet Explorer 7 and before, the box model is broken, causing the browser to treat the width/height of the actual rotated filtered image as the width/height of the box itself, but Microsoft corrected that in IE8. We must use a negative offset in IE8 on the right/bottom
dif=(i<2)?-t.ieOffsetX:-t.ieOffsetY;//if another tween is controlling a margin, we cannot only apply the difference in the ieOffsets, so we essentially zero-out the dx and dy here in that case. We record the margin(s) later so that we can keep comparing them, making this code very flexible.
if(skewY){//for performance reasons, we combine all skewing into the skewX and rotation values. Remember, a skewY of 10 degrees looks the same as a rotation of 10 degrees plus a skewX of 10 degrees.
skewX+=skewY;
angle+=skewY;
}
//check to see if we should render as 2D (and SVGs must use 2D when _useSVGTransformAttr is true)
if(((((v===1||v===0)&&force3D==="auto"&&(this.tween._totalTime===this.tween._totalDuration||!this.tween._totalTime))||!force3D)&&!z&&!perspective&&!rotationY&&!rotationX&&sz===1)||(_useSVGTransformAttr&&isSVG)||!_supports3D){//on the final render (which could be 0 for a from tween), if there are no 3D aspects, render in 2D to free up memory and improve performance especially on mobile devices. Check the tween's totalTime/totalDuration too in order to make sure it doesn't happen between repeats if it's a repeating tween.
//2D
if(angle||skewX||isSVG){
angle*=_DEG2RAD;
skew=skewX*_DEG2RAD;
rnd=100000;
a11=Math.cos(angle)*sx;
a21=Math.sin(angle)*sx;
a12=Math.sin(angle-skew)*-sy;
a22=Math.cos(angle-skew)*sy;
if(skew&&t.skewType==="simple"){//by default, we compensate skewing on the other axis to make it look more natural, but you can set the skewType to "simple" to use the uncompensated skewing that CSS does
if(_useSVGTransformAttr&&(t.xPercent||t.yPercent)){//The SVG spec doesn't support percentage-based translation in the "transform" attribute, so we merge it into the matrix to simulate it.
//some browsers have a hard time with very small values like 2.4492935982947064e-16 (notice the "e-" towards the end) and would render the object slightly off. So we round to 5 decimal places.
if(_isFirefox){//Firefox has a bug (at least in v25) that causes it to render the transparent part of 32-bit PNG images as black when displayed inside an iframe and the 3D scale is very small and doesn't change sufficiently enough between renders (like if you use a Power4.easeInOut to scale from 0 to 1 where the beginning values only change a tiny amount to begin the tween before accelerating). In this case, we force the scale to be 0.00002 instead which is visually the same but works around the Firefox issue.
min=0.0001;
if(sx<min&&sx>-min){
sx=sz=0.00002;
}
if(sy<min&&sy>-min){
sy=sz=0.00002;
}
if(perspective&&!t.z&&!t.rotationX&&!t.rotationY){//Firefox has a bug that causes elements to have an odd super-thin, broken/dotted black border on elements that have a perspective set but aren't utilizing 3D space (no rotationX, rotationY, or z).
perspective=0;
}
}
if(angle||skewX){
angle*=_DEG2RAD;
cos=a11=Math.cos(angle);
sin=a21=Math.sin(angle);
if(skewX){
angle-=skewX*_DEG2RAD;
cos=Math.cos(angle);
sin=Math.sin(angle);
if(t.skewType==="simple"){//by default, we compensate skewing on the other axis to make it look more natural, but you can set the skewType to "simple" to use the uncompensated skewing that CSS does
t1=Math.tan((skewX-skewY)*_DEG2RAD);
t1=Math.sqrt(1+t1*t1);
cos*=t1;
sin*=t1;
if(t.skewY){
t1=Math.tan(skewY*_DEG2RAD);
t1=Math.sqrt(1+t1*t1);
a11*=t1;
a21*=t1;
}
}
}
a12=-sin;
a22=cos;
}elseif(!rotationY&&!rotationX&&sz===1&&!perspective&&!isSVG){//if we're only translating and/or 2D scaling, this is faster...
z=0;//don't use string because we calculate perspective later and need the number.
}
}
//optimized way of concatenating all the values into a string. If we do it all in one shot, it's slower because of the way browsers have to create temp strings and the way it affects memory. If we do it piece-by-piece with +=, it's a bit slower too. We found that doing it in these sized chunks works best overall:
if(cssp._lastParsedTransform===vars){returnpt;}//only need to parse the transform once, and only if the browser supports it.
cssp._lastParsedTransform=vars;
varscaleFunc=(vars.scale&&typeof(vars.scale)==="function")?vars.scale:0;//if there's a function-based "scale" value, swap in the resulting numeric value temporarily. Otherwise, if it's called for both scaleX and scaleY independently, they may not match (like if the function uses Math.random()).
if(orig&&typeof(orig)==="string"&&_transformProp){//for values like transform:"rotate(60deg) scale(0.5, 0.8)"
copy=_tempDiv.style;//don't use the original target because it might be SVG in which case some browsers don't report computed style correctly.
copy[_transformProp]=orig;
copy.display="block";//if display is "none", the browser often refuses to report the transform properties correctly.
copy.position="absolute";
if(orig.indexOf("%")!==-1){//%-based translations will fail unless we set the width/height to match the original target...
copy.width=_getStyle(t,"width");
copy.height=_getStyle(t,"height");
}
_doc.body.appendChild(_tempDiv);
m2=_getTransform(_tempDiv,null,false);
if(m1.skewType==="simple"){//the default _getTransform() reports the skewX/scaleY as if skewType is "compensated", thus we need to adjust that here if skewType is "simple".
m2.scaleY*=Math.cos(m2.skewX*_DEG2RAD);
}
if(m1.svg){//if it's an SVG element, x/y part of the matrix will be affected by whatever we use as the origin and the offsets, so compensate here...
x=m1.xOrigin;
y=m1.yOrigin;
m2.x-=m1.xOffset;
m2.y-=m1.yOffset;
if(v.transformOrigin||v.svgOrigin){//if this tween is altering the origin, we must factor that in here. The actual work of recording the transformOrigin values and setting up the PropTween is done later (still inside this function) so we cannot leave the changes intact here - we only want to update the x/y accordingly.
pt.e=endRotations[p];//directional rotations typically have compensated values during the tween, but we need to make sure they end at exactly what the user requested
}
pt.xs0=0;//ensures the value stays numeric in setRatio()
x=m1.xOffset;//when we change the origin, in order to prevent things from jumping we adjust the x/y so we must record those here so that we can create PropTweens for them and flip them at the same time as the origin
pt=_addNonTweeningNumericPT(m1,"xOrigin",(originalGSTransform?m1:m2).xOrigin,m2.xOrigin,pt,transformOriginString);//note: if there wasn't a transformOrigin defined yet, just start with the destination one; it's wasteful otherwise, and it causes problems with fromTo() tweens. For example, TweenLite.to("#wheel", 3, {rotation:180, transformOrigin:"50% 50%", delay:1}); TweenLite.fromTo("#wheel", 3, {scale:0.5, transformOrigin:"50% 50%"}, {scale:1, delay:2}); would cause a jump when the from values revert at the beginning of the 2nd tween.
orig="0px 0px";//certain browsers (like firefox) completely botch transform-origin, so we must remove it to prevent it from contaminating transforms. We manage it ourselves with xOrigin and yOrigin
}
if(orig||(_supports3D&&has3D&&m1.zOrigin)){//if anything 3D is happening and there's a transformOrigin with a z component that's non-zero, we must ensure that the transformOrigin's z-component is set to 0 so that we can manually do those calculations to get around Safari bugs. Even if the user didn't specifically define a "transformOrigin" in this particular tween (maybe they did it via css directly).
m1.zOrigin=((orig.length>2)?parseFloat(orig[2]):copy)||0;//Safari doesn't handle the z part of transformOrigin correctly, so we'll manually handle it in the _set3DTransformRatio() method.
pt.xs0=pt.e=orig[0]+" "+(orig[1]||"50%")+" 0px";//we must define a z value of 0px specifically otherwise iOS 5 Safari will stick with the old one (if one was defined)!
pt=newCSSPropTween(m1,"zOrigin",0,0,pt,-1,pt.n);//we must create a CSSPropTween for the _gsTransform.zOrigin so that it gets reset properly at the beginning if the tween runs backward (as opposed to just setting m1.zOrigin here)
pt.b=copy;
pt.xs0=pt.e=m1.zOrigin;
}else{
pt.xs0=pt.e=orig;
}
//for older versions of IE (6-8), we need to manually calculate things inside the setRatio() function. We record origin x and y (ox and oy) and whether or not the values are percentages (oxp and oyp).
}else{
_parsePosition(orig+"",m1);
}
}
if(hasChange){
cssp._transformType=(!(m1.svg&&_useSVGTransformAttr)&&(has3D||this._transformType===3))?3:2;//quicker than calling cssp._enableTransforms();
for(i=0;i<props.length;i++){//if we're dealing with percentages, we must convert things separately for the horizontal and vertical axis!
if(this.p.indexOf("border")){//older browsers used a prefix
props[i]=_checkPropPrefix(props[i]);
}
bs=bs2=_getStyle(t,props[i],_cs,false,"0px");
if(bs.indexOf(" ")!==-1){
bs2=bs.split(" ");
bs=bs2[0];
bs2=bs2[1];
}
es=es2=ea1[i];
bn=parseFloat(bs);
bsfx=bs.substr((bn+"").length);
rel=(es.charAt(1)==="=");
if(rel){
en=parseInt(es.charAt(0)+"1",10);
es=es.substr(2);
en*=parseFloat(es);
esfx=es.substr((en+"").length-(en<0?1:0))||"";
}else{
en=parseFloat(es);
esfx=es.substr((en+"").length);
}
if(esfx===""){
esfx=_suffixMap[p]||bsfx;
}
if(esfx!==bsfx){
hn=_convertToPixels(t,"borderLeft",bn,bsfx);//horizontal number (we use a bogus "borderLeft" property just because the _convertToPixels() method searches for the keywords "Left", "Right", "Top", and "Bottom" to determine of it's a horizontal or vertical property, and we need "border" in the name so that it knows it should measure relative to the element itself, not its parent.
vn=_convertToPixels(t,"borderTop",bn,bsfx);//vertical number
bs=this.format(((cs)?_ieVers?cs.getPropertyValue(bp+"-x")+" "+cs.getPropertyValue(bp+"-y"):cs.getPropertyValue(bp):t.currentStyle.backgroundPositionX+" "+t.currentStyle.backgroundPositionY)||"0 0"),//Internet Explorer doesn't report background-position correctly - we must query background-position-x and background-position-y and combine them (even in IE10). Before IE9, we must do the same with the currentStyle object and use camelCase
return(v.substr(0,2)==="co")?v:_parsePosition(v.indexOf(" ")===-1?v+" "+v:v);//if set to something like "100% 100%", Safari typically reports the computed style as just "100%" (no 2nd value), but we should ensure that there are two values, so copy the first one. Otherwise, it'd be interpreted as "100% 0" (wrong). Also remember that it could be "cover" or "contain" which we can't tween but should be able to set.
if(_ieVers<9){//IE8 and earlier don't report a "clip" value in the currentStyle - instead, the values are split apart into clipTop, clipRight, clipBottom, and clipLeft. Also, in IE7 and earlier, the values inside rect() are space-delimited, not comma-delimited.
_registerComplexSpecialProp("autoRound,strictUnits",{parser:function(t,e,p,cssp,pt){returnpt;}});//just so that we can ignore these properties (not tween them)
_registerComplexSpecialProp("borderWidth",{parser:_getEdgeParser("borderTopWidth,borderRightWidth,borderBottomWidth,borderLeftWidth")});//Firefox doesn't pick up on borderWidth set in style sheets (only inline).
if(val===100){//for older versions of IE that need to use a filter to apply opacity, we should remove the filter if opacity hits 1 in order to improve performance, but make sure there isn't a transform (matrix) or gradient in the filters.
skip=(!_getStyle(this.data,"filter"));//if a class is applied that has an alpha filter, it will take effect (we don't want that), so re-apply our alpha filter in that case. We must first remove it and then check.
}else{
t.filter=filters.replace(_alphaFilterExp,"");
skip=true;
}
}
if(!skip){
if(this.xn1){
t.filter=filters=filters||("alpha(opacity="+val+")");//works around bug in IE7/8 that prevents changes to "visibility" from being applied properly if the filter is changed to a different alpha on the same frame.
}
if(filters.indexOf("pacity")===-1){//only used if browser doesn't support the standard opacity style property (IE 7 and 8). We omit the "O" to avoid case-sensitivity issues
if(val!==0||!this.xn1){//bugs in IE7/8 won't render the filter properly if opacity is ADDED on the same frame/render as "visibility" changes (this.xn1 is 1 if this tween is an "autoAlpha" tween)
t.filter=filters+" alpha(opacity="+val+")";//we round the value because otherwise, bugs in IE7/8 can prevent "visibility" changes from being applied properly.
if(isAutoAlpha&&b===1&&_getStyle(t,"visibility",_cs)==="hidden"&&e!==0){//if visibility is initially set to "hidden", we should interpret that as intent to make opacity 0 (a convenience)
pt.xn1=isAutoAlpha?1:0;//we need to record whether or not this is an autoAlpha so that in the setRatio(), we know to duplicate the setting of the alpha in order to work around a bug in IE7 and IE8 that prevents changes to "visibility" from taking effect if the filter is changed to a different alpha(opacity) at the same time. Setting it to the SAME value first, then the new value works around the IE7/8 bug.
style.zoom=1;//helps correct an IE issue.
pt.type=2;
pt.b="alpha(opacity="+pt.s+")";
pt.e="alpha(opacity="+(pt.s+pt.c)+")";
pt.data=t;
pt.plugin=plugin;
pt.setRatio=_setIEOpacityRatio;
}
if(isAutoAlpha){//we have to create the "visibility" PropTween after the opacity one in the linked list so that they run in the order that works properly in IE8 and earlier
if(p.substr(0,2)==="ms"||p.substr(0,6)==="webkit"){//Microsoft and some Webkit browsers don't conform to the standard of capitalizing the first prefix character, so we adjust so that when we prefix the caps with a dash, it's correct (otherwise it'd be "ms-transform" instead of "-ms-transform" for IE9, for example)
varb=t.getAttribute("class")||"",//don't use t.className because it doesn't work consistently on SVG elements; getAttribute("class") and setAttribute("class", value") is more reliable.
//if there's a className tween already operating on the target, force it to its end so that the necessary inline styles are removed and the class name is applied before we determine the end state (we don't want inline styles interfering that were there just for class-specific values)
cnpt=t._gsClassPT;
if(cnpt){
cnptLookup={};
mpt=cnpt.data;//first MiniPropTween which stores the inline styles - we need to force these so that the inline styles don't contaminate things. Otherwise, there's a small chance that a tween could start and the inline values match the destination values and they never get cleaned.
if(t.style.cssText!==cssText){//only apply if things change. Otherwise, in cases like a background-image that's pulled dynamically, it could cause a refresh. See https://greensock.com/forums/topic/20368-possible-gsap-bug-switching-classnames-in-chrome/.
t.style.cssText=cssText;//we recorded cssText before we swapped classes and ran _getAllStyles() because in cases when a className tween is overwritten, we remove all the related tweening properties from that class change (otherwise class-specific stuff can't override properties we've directly set on the target's style object due to specificity).
}
pt=pt.xfirst=cssp.parse(t,difData.difs,pt,plugin);//we record the CSSPropTween as the xfirst so that we can handle overwriting propertly (if "className" gets overwritten, we must kill all the properties associated with the className part of the tween, so we can loop through from xfirst to the pt itself)
returnpt;
}});
var_setClearPropsRatio=function(v){
if(v===1||v===0)if(this.data._totalTime===this.data._totalDuration&&this.data.data!=="isFromStart"){//this.data refers to the tween. Only clear at the END of the tween (remember, from() tweens make the ratio go from 1 to 0, so we can't just check that and if the tween is the zero-duration one that's created internally to render the starting values in a from() tween, ignore that because otherwise, for example, from(...{height:100, clearProps:"height", delay:1}) would wipe the height at the beginning of the tween and after 1 second, it'd kick back in).
vars=this.t.style,
transformParse=_specialProps.transform.parse,
a,p,i,clearTransform,transform;
if(this.e==="all"){
s.cssText="";
clearTransform=true;
}else{
a=this.e.split(" ").join("").split(",");
i=a.length;
while(--i>-1){
p=a[i];
if(_specialProps[p]){
if(_specialProps[p].parse===transformParse){
clearTransform=true;
}else{
p=(p==="transformOrigin")?_transformOriginProp:_specialProps[p].p;//ensures that special properties use the proper browser-specific property name, like "scaleX" might be "-webkit-transform" or "boxShadow" might be "-moz-box-shadow"
//gets called when the tween renders for the first time. This kicks everything off, recording start/end values, etc.
p._onInitTween=function(target,vars,tween,index){
if(!target.nodeType){//css is only for dom elements
returnfalse;
}
this._target=_target=target;
this._tween=tween;
this._vars=vars;
_index=index;
_autoRound=vars.autoRound;
_hasPriority=false;
_suffixMap=vars.suffixMap||CSSPlugin.suffixMap;
_cs=_getComputedStyle(target,"");
_overwriteProps=this._overwriteProps;
varstyle=target.style,
v,pt,pt2,first,last,next,zIndex,tpt,threeD;
if(_reqSafariFix)if(style.zIndex===""){
v=_getStyle(target,"zIndex",_cs);
if(v==="auto"||v===""){
//corrects a bug in [non-Android] Safari that prevents it from repainting elements in their new positions if they don't have a zIndex set. We also can't just apply this inside _parseTransform() because anything that's moved in any way (like using "left" or "top" instead of transforms like "x" and "y") can be affected, so it is best to ensure that anything that's tweening has a z-index. Setting "WebkitPerspective" to a non-zero value worked too except that on iOS Safari things would flicker randomly. Plus zIndex is less memory-intensive.
this._addLazySet(style,"zIndex",0);
}
}
if(typeof(vars)==="string"){
first=style.cssText;
v=_getAllStyles(target,_cs);
style.cssText=first+";"+vars;
v=_cssDif(target,v,_getAllStyles(target)).difs;
if(!_supportsOpacity&&_opacityValExp.test(vars)){
v.opacity=parseFloat(RegExp.$1);
}
vars=v;
style.cssText=first;
}
if(vars.className){//className tweens will combine any differences they find in the css with the vars that are passed in, so {className:"myClass", scale:0.5, left:20} would work.
// 1) [non-Android] Safari skips rendering changes to "top" and "left" that are made on the same frame/render as a transform update.
// 2) iOS Safari sometimes neglects to repaint elements in their new positions. Setting "WebkitPerspective" to a non-zero value worked too except that on iOS Safari things would flicker randomly.
// 3) Safari sometimes displayed odd artifacts when tweening the transform (or WebkitTransform) property, like ghosts of the edges of the element remained. Definitely a browser bug.
//Note: we allow the user to override the auto-setting by defining WebkitBackfaceVisibility in the vars of the tween.
tpt.pr=-1;//ensures that the transforms get applied after the components are updated.
_overwriteProps.pop();//we don't want to force the overwrite of all "transform" tweens of the target - we only care about individual transform properties like scaleX, rotation, etc. The CSSPropTween constructor automatically adds the property to _overwriteProps which is why we need to pop() here.
}
if(_hasPriority){
//reorders the linked list in order of pr (priority)
while(pt){
next=pt._next;
pt2=first;
while(pt2&&pt2.pr>pt.pr){
pt2=pt2._next;
}
if((pt._prev=pt2?pt2._prev:last)){
pt._prev._next=pt;
}else{
first=pt;
}
if((pt._next=pt2)){
pt2._prev=pt;
}else{
last=pt;
}
pt=next;
}
this._firstPT=first;
}
returntrue;
};
p.parse=function(target,vars,pt,plugin){
varstyle=target.style,
p,sp,bn,en,bs,es,bsfx,esfx,isStr,rel;
for(pinvars){
es=vars[p];//ending value string
sp=_specialProps[p];//SpecialProp lookup.
if(typeof(es)==="function"&&!(sp&&sp.allowFunc)){
es=es(_index,_target);
}
if(sp){
pt=sp.parse(target,es,p,this,pt,plugin,vars);
}elseif(p.substr(0,2)==="--"){//for tweening CSS variables (which always start with "--"). To maximize performance and simplicity, we bypass CSSPlugin altogether and just add a normal property tween to the tween instance itself.
if(p==="color"||p==="fill"||p==="stroke"||p.indexOf("Color")!==-1||(isStr&&_rgbhslExp.test(es))){//Opera uses background: to define color sometimes in addition to backgroundColor:
bsfx=(bn||bn===0)?bs.substr((bn+"").length):"";//remember, bs could be non-numeric like "normal" for fontWeight, so we should default to a blank suffix in that case.
if(bs===""||bs==="auto"){
if(p==="width"||p==="height"){
bn=_getDimension(target,p,_cs);
bsfx="px";
}elseif(p==="left"||p==="top"){
bn=_calculateOffset(target,p,_cs);
bsfx="px";
}else{
bn=(p!=="opacity")?0:1;
bsfx="";
}
}
rel=(isStr&&es.charAt(1)==="=");
if(rel){
en=parseInt(es.charAt(0)+"1",10);
es=es.substr(2);
en*=parseFloat(es);
esfx=es.replace(_suffixExp,"");
}else{
en=parseFloat(es);
esfx=isStr?es.replace(_suffixExp,""):"";
}
if(esfx===""){
esfx=(pin_suffixMap)?_suffixMap[p]:bsfx;//populate the end suffix, prioritizing the map, then if none is found, use the beginning suffix.
}
es=(en||en===0)?(rel?en+bn:en)+esfx:vars[p];//ensures that any += or -= prefixes are taken care of. Record the end value before normalizing the suffix because we always want to end the tween on exactly what they intended even if it doesn't match the beginning value's suffix.
//if the beginning/ending suffixes don't match, normalize them...
if(bsfx!==esfx)if(esfx!==""||p==="lineHeight")if(en||en===0)if(bn){//note: if the beginning value (bn) is 0, we don't need to convert units!
bn=_convertToPixels(target,p,bn,bsfx);
if(esfx==="%"){
bn/=_convertToPixels(target,p,100,"%")/100;
if(vars.strictUnits!==true){//some browsers report only "px" values instead of allowing "%" with getComputedStyle(), so we assume that if we're tweening to a %, we should start there too unless strictUnits:true is defined. This approach is particularly useful for responsive designs that use from() tweens.
esfx="px";//we don't use bsfx after this, so we don't need to set it to px too.
}
if(rel)if(en||en===0){
es=(en+bn)+esfx;//the changes we made affect relative calculations, so adjust the end value here.
}
}
if(rel){
en+=bn;
}
if((bn||bn===0)&&(en||en===0)){//faster than isNaN(). Also, previously we required en !== bn but that doesn't really gain much performance and it prevents _parseToProxy() from working properly if beginning and ending values match but need to get tweened by an external plugin anyway. For example, a bezier tween where the target starts at left:0 and has these points: [{left:50},{left:0}] wouldn't work properly because when parsing the last point, it'd match the first (current) one and a non-tweening CSSPropTween would be recorded when we actually need a normal tween (type:0) so that things get updated during the tween properly.
pt.xs0=(es==="none"&&(p==="display"||p.indexOf("Style")!==-1))?bs:es;//intermediate value should typically be set immediately (end value) except for "display" or things like borderTopStyle, borderBottomStyle, etc. which should use the beginning value during the tween.
//DEBUG: _log("non-tweening value "+p+": "+pt.xs0);
}
}
}
if(plugin)if(pt&&!pt.plugin){
pt.plugin=plugin;
}
}
returnpt;
};
//gets called every time the tween updates, passing the new ratio (typically a value between 0 and 1, but not always (for example, if an Elastic.easeOut is used, the value can jump above 1 mid-tween). It will always start and 0 and end at 1.
p.setRatio=function(v){
varpt=this._firstPT,
min=0.000001,
val,str,i;
//at the end of the tween, we set the values to exactly what we received in order to make sure non-tweening values (like "position" or "float" or whatever) are set and so that if the beginning/ending suffixes (units) didn't match and we normalized to px, the value that the user passed in is used here. We check to see if the tween is at its beginning in case it's a from() tween in which case the ratio will actually go from 1 to 0 over the course of the tween (backwards).
}elseif(pt.setRatio){//custom setRatio() for things like SpecialProps, external plugins, etc.
pt.setRatio(v);
}
pt=pt._next;
}
//if the tween is reversed all the way back to the beginning, we need to restore the original values which may have different units (like % instead of px or em or whatever).
}else{
while(pt){
if(pt.type!==2){
pt.t[pt.p]=pt.b;
}else{
pt.setRatio(v);
}
pt=pt._next;
}
}
};
/**
*@private
*Forcesrenderingofthetarget's transforms (rotation, scale, etc.) whenever the CSSPlugin'ssetRatio()iscalled.
this._transform=this._transform||_getTransform(this._target,_cs,true);//ensures that the element has a _gsTransform property with the appropriate values.
this.data._linkCSSP(this,this._next,null,true);//we purposefully keep this._next even though it'd make sense to null it, but this is a performance optimization, as this happens during the while (pt) {} loop in setRatio() at the bottom of which it sets pt = pt._next, so if we null it, the linked list will be broken in that loop.
};
/** @private Gives us a way to set a value on the first render (and only the first render). **/
remove=true;//just to prevent resetting this._firstPT 5 lines down in case pt._next is null. (optimized for speed)
}
if(prev){
prev._next=pt;
}elseif(!remove&&this._firstPT===null){
this._firstPT=pt;
}
pt._next=next;
pt._prev=prev;
}
returnpt;
};
p._mod=function(lookup){
varpt=this._firstPT;
while(pt){
if(typeof(lookup[pt.p])==="function"){//only gets called by RoundPropsPlugin (ModifyPlugin manages all the rendering internally for CSSPlugin properties that need modification). Remember, we handle rounding a bit differently in this plugin for performance reasons, leveraging "r" as an indicator that the value should be rounded internally.
pt.r=lookup[pt.p];
}
pt=pt._next;
}
};
//we need to make sure that if alpha or autoAlpha is killed, opacity is too. And autoAlpha affects the "visibility" property.
p._kill=function(lookup){
varcopy=lookup,
pt,p,xfirst;
if(lookup.autoAlpha||lookup.alpha){
copy={};
for(pinlookup){//copy the lookup so that we're not changing the original which may be passed elsewhere.
copy[p]=lookup[p];
}
copy.opacity=1;
if(copy.autoAlpha){
copy.visibility=1;
}
}
if(lookup.className&&(pt=this._classNamePT)){//for className tweens, we need to kill any associated CSSPropTweens too; a linked list starts at the className's "xfirst".
xfirst=pt.xfirst;
if(xfirst&&xfirst._prev){
this._linkCSSP(xfirst._prev,pt._next,xfirst._prev._prev);//break off the prev
*-Wecan't just create new independent tweens because otherwise, what happens if the original/parent tween is reversed or pause or dropped into a TimelineLite for tight control? You'dexpectthattween'sbehaviortoaffectalltheothers.
*-Analyzingeverystylepropertyofeverychildbeforeandafterthetweenisanexpensiveoperationwhentherearemanychildren,sothisbehaviorshouldn't be imposed on all className tweens by default, especially since it'sprobablyrarethatthisextrafunctionalityisneeded.
//called when the tween renders for the first time. This is where initial values should be recorded and any setup routines should run.
init:function(target,value,tween){
this._tween=tween;
returntrue;
}
}),
_getRoundFunc=function(v){//pass in 0.1 get a function that'll round to the nearest tenth, or 5 to round to the closest 5, or 0.001 to the closest 1000th, etc.
varp=v<1?Math.pow(10,(v+"").length-2):1;//to avoid floating point math errors (like 24 * 0.1 == 2.4000000000000004), we chop off at a specific number of decimal places (much faster than toFixed()
returnfunction(n){
return((Math.round(n/v)*v*p)|0)/p;
};
},
_roundLinkedList=function(node,mod){
while(node){
if(!node.f&&!node.blob){
node.m=mod||Math.round;
}
node=node._next;
}
},
p=RoundPropsPlugin.prototype;
p._onInitAllProps=function(){
vartween=this._tween,
rp=tween.vars.roundProps,
lookup={},
rpt=tween._propLookup.roundProps,
pt,next,i,p;
if(typeof(rp)==="object"&&!rp.push){
for(pinrp){
lookup[p]=_getRoundFunc(rp[p]);
}
}else{
if(typeof(rp)==="string"){
rp=rp.split(",");
}
i=rp.length;
while(--i>-1){
lookup[rp[i]]=Math.round;
}
}
for(pinlookup){
pt=tween._firstPT;
while(pt){
next=pt._next;//record here, because it may get removed
//called each time the values should be updated, and the ratio gets passed as the only parameter (typically it's a value between 0 and 1, but it can exceed those when using an ease like Elastic.easeOut or Back.easeOut, etc.)
_easeReg=Ease.register||function(){},//put an empty function in place just as a safety measure in case someone loads an OLD version of TweenLite.js where Ease.register doesn't exist.
returnthis._calcEnd?(p===1?0:1-(p=(p-this._p3)/this._p1)*p):r+((p-r)*(p=(p-this._p3)/this._p1)*p*p*p);//added p === 1 ? 0 to avoid floating point rounding errors from affecting the final value, like 1 - 0.7 = 0.30000000000000004 instead of 0.3
this._p1=(amplitude>=1)?amplitude:1;//note: if amplitude is < 1, we simply adjust the period for a more natural feel. Otherwise the math doesn't work right and the curve starts at 1.
returnexistingModule;//in case the core set of classes is already loaded, don't instantiate twice.
}
var_namespace=function(ns){
vara=ns.split("."),
p=_globals,i;
for(i=0;i<a.length;i++){
p[a[i]]=p=p[a[i]]||{};
}
returnp;
},
gs=_namespace("com.greensock"),
_tinyNum=0.00000001,
_slice=function(a){//don't use Array.prototype.slice.call(target, 0) 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;
},
_emptyFunc=function(){},
_isArray=(function(){//works around issues in iframe environments where the Array global isn't shared, thus if the object originates in a different window/iframe, "(obj instanceof Array)" will evaluate false. We added some speed optimizations to avoid Object.prototype.toString.call() unless it's absolutely necessary because it's VERY slow (like 20x slower)
*vargs=window.GreenSockGlobals={};//the newer version we're about to load could now be referenced in a "gs" object, like gs.TweenLite.to(...). Use whatever alias you want as long as it's unique, "gs" or "banner" or whatever.
*window.GreenSockGlobals=window._gsQueue=window._gsDefine=null;//reset it back to null (along with the special _gsQueue variable) so that the next load of TweenMax affects the window and we can reference things directly like TweenLite.to(...)
_globals[n]=_exports[n]=cl;//provides a way to avoid global namespace pollution. By default, the main classes like TweenLite, Power1, Strong, etc. are added to window unless a GreenSockGlobals is defined. So if you want to have things added to a custom object instead, just do something like window.GreenSockGlobals = {} before loading any GreenSock files. You can even set up an alias like window.GreenSockGlobals = windows.gs = {} so that you can access everything like gs.TweenLite. Also remember that ALL classes are added to the window.com.greensock object (in their respective packages, like com.greensock.easing.Power1, com.greensock.TweenLite, etc.)
//a quick way to create a class that doesn't have any dependencies. Returns the class, but first registers it in the GreenSock namespace so that other classes can grab it (other classes might be dependent on the class).
//create all the standard eases like Linear, Quad, Cubic, Quart, Quint, Strong, Power0, Power1, Power2, Power3, and Power4 (each with easeIn, easeOut, and easeInOut)
//now try to determine the requestAnimationFrame and cancelAnimationFrame functions and if none are found, we'll use a setTimeout()/clearTimeout() polyfill.
if(manual!==true){//make sure the request is made before we dispatch the "tick" event so that timing is maintained. Otherwise, if processing the "tick" requires a bunch of time (like 15ms) and we're using a setTimeout() that's based on 16.7ms, it'd technically take 31.7ms between frames otherwise.
if(!arguments.length){//if lagSmoothing() is called with no arguments, treat it like a getter that returns a boolean indicating if it's enabled or not. This is purposely undocumented and is for internal use.
return(_lagThreshold<1/_tinyNum);
}
_lagThreshold=threshold||(1/_tinyNum);//zero should be interpreted as basically unlimited
}elseif(_self.frame>10){//don't trigger lagSmoothing if we're just waking up, and make sure that at least 10 frames have elapsed because of the iOS bug that we work around below with the 1.5-second setTimout().
//a bug in iOS 6 Safari occasionally prevents the requestAnimationFrame from working initially, so we use a 1.5-second timeout that automatically falls back to setTimeout() if it senses this condition.
if(!_tickerActive){//some browsers (like iOS 6 Safari) shut down JavaScript execution when the tab is disabled and they [occasionally] neglect to start up requestAnimationFrame again when returning - this code ensures that the engine starts up again properly.
//some browsers (like iOS) occasionally drop the requestAnimationFrame event when the user switches to a different tab and then comes back again, so we use a 2-second setTimeout() to sense if/when that condition occurs and then wake() the ticker.
var_checkTimeout=function(){
if(_tickerActive&&_getTime()-_lastUpdate>2000&&((_doc||{}).visibilityState!=="hidden"||!_ticker.lagSmoothing())){//note: if the tab is hidden, we should still wake if lagSmoothing has been disabled.
_ticker.wake();
}
vart=setTimeout(_checkTimeout,2000);
if(t.unref){
// allows a node process to exit even if the timeout’s callback hasn't been invoked. Without it, the node process could hang as this function is called every two seconds.
switch(l){//speed optimization; call() is faster than apply() so use it when there are only a few parameters (which is by far most common). Previously we simply did var v = this.vars; v[type].apply(v[type + "Scope"] || v.callbackScope || this, v[type + "Params"] || _blankArray);
if(!tl._dirty){//for performance improvement. If the parent's cache is already dirty, it already took care of marking the ancestors as dirty too, so skip the function call here.
this._uncache(false);
}
//in case any of the ancestor timelines had completed but should now be enabled, we should reset their totalTime() which will also ensure that they're lined up properly and enabled. Skip for animations that are on the root (wasteful). Example: a TimelineLite.exportRoot() is performed when there's a paused tween on the root, the export will not complete until that tween is unpaused, but imagine a child gets restarted later, after all [unpaused] tweens have completed. The startTime of that child would get pushed out, but one of the ancestors may have completed.
if(_lazyTweens.length){//in case rendering caused any tweens to lazy-init, we should render them because typically when someone calls seek() or time() or progress(), they expect an immediate render.
this.timeline.add(this,value-this._delay);//ensures that any necessary re-sequencing of Animations in the timeline occurs to make sure the rendering order is correct.
while(t&&t.timeline){//must update the duration/totalDuration of all ancestor timelines immediately in case in the middle of a render loop, one tween alters another tween's timeScale which shoves its startTime before 0, forcing the parent timeline to shift around and shiftChildren() which could affect that next tween's render (startTime). Doesn't matter for the root timeline though.
this.render(raw,(raw===this._totalTime),true);//in case the target's properties changed via some other tween or manual update by the user, we should force a render.
if(child._paused)if(this!==child._timeline){//we only adjust the _pauseTime if it wasn't in this timeline already. Remember, sometimes a tween will be inserted again into the same timeline when its startTime is changed so that the tweens in the TimelineLite/Max are re-ordered properly in the linked list (so everything renders in the proper order).
this._targets=targets=_slice(target);//don't use Array.prototype.slice.call(target, 0) because that doesn't work in IE8 with a NodeList that's returned by querySelectorAll()
this._propLookup=[];
this._siblings=[];
for(i=0;i<targets.length;i++){
targ=targets[i];
if(!targ){
targets.splice(i--,1);
continue;
}elseif(typeof(targ)==="string"){
targ=targets[i--]=TweenLite.selector(targ);//in case it's an array of strings
if(typeof(targ)==="string"){
targets.splice(i+1,1);//to avoid an endless loop (can't imagine why the selector would return a string, but just in case)
}
continue;
}elseif(targ.length&&targ!==window&&targ[0]&&(targ[0]===window||(targ[0].nodeType&&targ[0].style&&!targ.nodeType))){//in case the user is passing in an array of selector objects (like jQuery objects), we need to check one more level and pull things out if necessary. Also note that <select> elements pass all the criteria regarding length and the first child having style, so we must also check to ensure the target isn't an HTML node itself.
this._time=-_tinyNum;//forces a render without having to set the render() "force" parameter to true because we want to allow lazying by default (using the "force" parameter always forces an immediate full render)
this.render(Math.min(0,-this._delay));//in case delay is negative
}
},true),
_isSelector=function(v){
return(v&&v.length&&v!==window&&v[0]&&(v[0]===window||(v[0].nodeType&&v[0].style&&!v.nodeType)));//we cannot check "nodeType" if the target is window from within an iframe, otherwise it will trigger a security error in some browsers like Firefox.
},
_autoCSS=function(vars,target){
varcss={},
p;
for(pinvars){
if(!_reservedProps[p]&&(!(pintarget)||p==="transform"||p==="x"||p==="y"||p==="width"||p==="height"||p==="className"||p==="border")&&(!_plugins[p]||(_plugins[p]&&_plugins[p]._autoCSS))){//note: <img> elements contain read-only "x" and "y" properties. We should also prioritize editing css width/height rather than the element's properties.
css[p]=vars[p];
deletevars[p];
}
}
vars.css=css;
};
p=TweenLite.prototype=newAnimation();
p.constructor=TweenLite;
p.kill()._gc=false;
//----TweenLite defaults, overwrite management, and root updates ----------------------------------------------------
}elseif(val<min)if(val>-min&&!pt.blob){//prevents issues with converting very small numbers to strings in the browser
val=0;
}
if(!pt.f){
pt.t[pt.p]=val;
}elseif(pt.fp){
pt.t[pt.p](pt.fp,val);
}else{
pt.t[pt.p](val);
}
pt=pt._next;
}
},
_blobRound=function(v){
return(((v*1000)|0)/1000)+"";
},
//compares two strings (start/end), finds the numbers that are different and spits back an array representing the whole value but with the changing values isolated as elements. For example, "rgb(0,0,0)" and "rgb(100,50,0)" would become ["rgb(", 0, ",", 50, ",0)"]. Notice it merges the parts that are identical (performance optimization). The array also has a linked list of PropTweens attached starting with _firstPT that contain the tweening data (t, p, s, c, f, etc.). It also stores the starting value as a "start" property so that we can revert to it if/when necessary, like when a tween rewinds fully. If the quantity of numbers differs between the start and end, it will always prioritize the end value(s). The pt parameter is optional - it's for a PropTween that will be appended to the end of the linked list and is typically for actually setting the value after all of the elements have been updated (with array.join("")).
_blobDif=function(start,end,filter,pt){
vara=[],
charIndex=0,
s="",
color=0,
startNums,endNums,num,i,l,nonNumbers,currentNum;
a.start=start;
a.end=end;
start=a[0]=start+"";//ensure values are strings
end=a[1]=end+"";
if(filter){
filter(a);//pass an array with the starting and ending values and let the filter do whatever it needs to the values.
start=a[0];
end=a[1];
}
a.length=0;
startNums=start.match(_numbersExp)||[];
endNums=end.match(_numbersExp)||[];
if(pt){
pt._next=null;
pt.blob=1;
a._firstPT=a._applyPT=pt;//apply last in the linked list (which means inserting it first)
s+=(nonNumbers||!i)?nonNumbers:",";//note: SVG spec allows omission of comma/space when a negative sign is wedged between two numbers, like 2.5-5.3 instead of 2.5,-5.3 but when tweening, the negative value may switch to positive, so we insert the comma just in case.
a._firstPT={_next:a._firstPT,t:a,p:a.length-1,s:num,c:((currentNum.charAt(1)==="=")?parseInt(currentNum.charAt(0)+"1",10)*parseFloat(currentNum.substr(2)):(parseFloat(currentNum)-num))||0,f:0,m:(color&&color<4)?Math.round:_blobRound};//limiting to 3 decimal places and casting as a string can really help performance when array.join() is called!
//note: we don't set _prev because we'll never need to remove individual PropTweens from this list.
}
charIndex+=currentNum.length;
}
s+=end.substr(charIndex);
if(s){
a.push(s);
}
a.setRatio=_setRatio;
if(_relExp.test(end)){//if the end string contains relative values, delete it so that on the final render (in _setRatio()), we don't actually set it to the string with += or -= characters (forces it to use the calculated value).
a.end=null;
}
returna;
},
//note: "funcParam" is only necessary for function-based getters/setters that require an extra parameter like getAttribute("width") and setAttribute("width", value). In this example, funcParam would be "width". Used by AttrPlugin for example.
pt={t:blob,p:"setRatio",s:0,c:1,f:2,pg:0,n:overwriteProp||prop,pr:0,m:0};//"2" indicates it's a Blob property tween. Needed for RoundPropsPlugin for example.
}else{
pt.s=parseFloat(s);
if(!isRelative){
pt.c=(parseFloat(end)-pt.s)||0;
}
}
}
if(pt.c){//only add it to the linked list if there's a change.
if((pt._next=this._firstPT)){
pt._next._prev=pt;
}
this._firstPT=pt;
returnpt;
}
},
_internals=TweenLite._internals={isArray:_isArray,isSelector:_isSelector,lazyTweens:_lazyTweens,blobDif:_blobDif},//gives us a way to expose certain private values to other GreenSock classes without contaminating tha main TweenLite object.
setTimeout(_lazyRender,1);//on some mobile devices, there isn't a "tick" before code runs which means any lazy renders wouldn't run before the next official "tick".
if(_lazyTweens.length){//if code is run outside of the requestAnimationFrame loop, there may be tweens queued AFTER the engine refreshed, so we need to ensure any pending renders occur before we refresh again.
//NOTE: Add tiny amount to overcome floating point errors that can cause the startTime to be VERY slightly off (when a tween's time() is set for example)
l=curTween._firstPT;//we need to discern if there were property tweens originally; if they all get removed in the next line's _kill() call, the tween should be killed. See https://github.com/greensock/GreenSock-JS/issues/278
startAt.render(-1,true);//if we've run a startAt previously (when the tween instantiated), we should revert it so that the values re-instantiate correctly particularly for relative tweens. Without this, a TweenLite.fromTo(obj, 1, {x:"+=100"}, {x:"-=100"}), for example, would actually jump to +=200 because the startAt would run twice, doubling the relative change.
startAt.kill();
}
startVars={};
for(pinv.startAt){//copy the properties/values into a new object to avoid collisions, like var to = {x:0}, from = {x:500}; timeline.fromTo(e, 1, from, to).fromTo(e, 1, to, from);
startVars[p]=v.startAt[p];
}
startVars.data="isStart";
startVars.overwrite=false;
startVars.immediateRender=true;
startVars.lazy=(immediate&&v.lazy!==false);
startVars.startAt=startVars.delay=null;//no nesting of startAt objects allowed (otherwise it could cause an infinite loop).
this._startAt=null;//tweens that render immediately (like most from() and fromTo() tweens) shouldn't revert when their parent timeline's playhead goes backward past the startTime because the initial render could have happened anytime and it shouldn't be directly correlated to this tween's startTime. Imagine setting up a complex animation where the beginning states of various objects are rendered immediately but the tween doesn't happen for quite some time - if we revert to the starting values as soon as the playhead goes backward past the tween's startTime, it will throw things off visually. Reversion should only happen in TimelineLite/Max instances where immediateRender was false (which is the default in the convenience methods like from()).
}elseif(dur!==0){
return;//we skip initialization here so that overwriting doesn't occur until the tween actually begins. Otherwise, if you create several immediateRender:true tweens of the same target/properties to drop into a TimelineLite or TimelineMax, the last one created would overwrite the first ones because they didn't get placed into the timeline yet before the first render occurs and kicks in overwriting.
}
}
}elseif(v.runBackwards&&dur!==0){
//from() tweens must be handled uniquely: their beginning values must be rendered but we don't want overwriting to occur yet (when time is still 0). Wait until the tween actually begins before doing all the routines like overwriting. At that time, we should render at the END of the tween to ensure that things initialize correctly (remember, from() tweens go backwards)
if(startAt){
startAt.render(-1,true);
startAt.kill();
this._startAt=null;
}else{
if(this._time!==0){//in rare cases (like if a from() tween runs and then is invalidate()-ed), immediateRender could be true but the initial forced-render gets skipped, so there's no need to force the render in this context when the _time is greater than 0
immediate=false;
}
pt={};
for(pinv){//copy props into a new object and skip any reserved props, otherwise onComplete or onUpdate or onStart could fire. We should, however, permit autoCSS to go through.
if(!_reservedProps[p]||p==="autoCSS"){
pt[p]=v[p];
}
}
pt.overwrite=0;
pt.data="isFromStart";//we tag the tween with as "isFromStart" so that if [inside a plugin] we need to only do something at the very END of a tween, we have a way of identifying this tween as merely the one that's setting the beginning values for a "from()" tween. For example, clearProps in CSSPlugin should only get applied at the very END of a tween and without this tag, from(...{height:100, clearProps:"height", delay:1}) would wipe the height at the beginning of the tween and after 1 second, it'd kick back in.
pt.lazy=(immediate&&v.lazy!==false);
pt.immediateRender=immediate;//zero-duration tweens render immediately by default, but if we're not specifically instructed to render this tween immediately, we should skip this and merely _init() to record the starting values (rendering them immediately would push them to completion which is wasteful in that case - we'd have to render(-1) immediately after)
this._startAt=TweenLite.to(this.target,0,pt);
if(!immediate){
this._startAt._init();//ensures that the initial values are recorded
this._startAt._enabled(false);//no need to have the tween render on the next cycle. Disable it because we'll always manually control the renders of the _startAt tween.
TweenLite._onPluginEvent("_onInitAllProps",this);//reorders the array in order of priority. Uses a static TweenPlugin method in order to minimize file size in TweenLite
}
if(op)if(!this._firstPT)if(typeof(this.target)!=="function"){//if all tweening properties have been overwritten, kill the tween. If the target is a function, it's probably a delayedCall so let it live.
_lazyRender();//if other tweens of the same target have recently initted but haven't rendered yet, we've got to force the render so that the starting values are correct (imagine populating a timeline with a bunch of sequential tweens and then jumping to the end)
}
if(!this.vars.css)if(target.style)if(target!==window&&target.nodeType)if(_plugins.css)if(this.vars.autoCSS!==false){//it's so common to use TweenLite/Max to animate the css of DOM elements, we assume that if the target is a DOM element, that's what is intended (a convenience so that users don't have to wrap things in css:{}, although we still recommend it for a slight performance boost and better specificity). Note: we cannot check "nodeType" on the window inside an iframe.
if(overwrittenProps)if(this._kill(overwrittenProps,target)){//another tween may have tried to overwrite properties of this tween before init() was called (like if two tweens start at the same time, the one created second will run first)
force=(force||self._timeline.autoRemoveChildren);//otherwise, if the animation is unpaused/activated after it's already finished, it doesn't get removed from the parent timeline.
}
if(duration===0)if(self._initted||!self.vars.lazy||force){//zero-duration tweens are tricky because we must discern the momentum/direction of time in order to determine whether the starting values should be rendered or the ending values. If the "playhead" of its timeline goes past the zero-duration tween in the forward direction or lands directly on it, the end values should be rendered, but if the timeline's "playhead" moves past it in the backward direction (from a postitive time to a negative time), the starting values must be rendered.
if(self._startTime===self._timeline._duration){//if a zero-duration tween is at the VERY end of a timeline and that timeline renders at its end, it will typically add a tiny bit of cushion to the render time to prevent rounding errors from getting in the way of tweens rendering their VERY end. If we then reverse() that timeline, the zero-duration tween will trigger its onReverseComplete even though technically the playhead didn't pass over it again. It's a very specific edge case we must accommodate.
time=0;
}
if(prevRawPrevTime<0||(time<=0&&time>=-_tinyNum)||(prevRawPrevTime===_tinyNum&&self.data!=="isPause"))if(prevRawPrevTime!==time){//note: when this.data is "isPause", it's a callback added by addPause() on a timeline that we should not be triggered when LEAVING its exact start time. In other words, tl.addPause(1).play(1) shouldn't pause.
force=true;
if(prevRawPrevTime>_tinyNum){
callback="onReverseComplete";
}
}
self._rawPrevTime=rawPrevTime=(!suppressEvents||time||prevRawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration 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.
}
}elseif(time<_tinyNum){//to work around occasional floating point math artifacts, round super small values to 0.
if(duration===0)if(self._initted||!self.vars.lazy||force){//zero-duration tweens are tricky because we must discern the momentum/direction of time in order to determine whether the starting values should be rendered or the ending values. If the "playhead" of its timeline goes past the zero-duration tween in the forward direction or lands directly on it, the end values should be rendered, but if the timeline's "playhead" moves past it in the backward direction (from a postitive time to a negative time), the starting values must be rendered.
self._rawPrevTime=rawPrevTime=(!suppressEvents||time||prevRawPrevTime===time)?time:_tinyNum;//when the playhead arrives at EXACTLY time 0 (right on top) of a zero-duration 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._initted||(self._startAt&&self._startAt.progress())){//if we render the very beginning (time == 0) of a fromTo(), we must force the render (normal tweens wouldn't need to render at a time of 0 when the prevTime was also 0). This is also mandatory to make sure overwriting kicks in immediately. Also, we check progress() because if startAt has already rendered at its end, we should force a render at its beginning. Otherwise, if you put the playhead directly on top of where a fromTo({immediateRender:false}) starts, and then move it backwards, the from() won't revert its values.
if(!self._initted||self._gc){//immediateRender tweens typically won't initialize until the playhead advances (_time is greater than 0) in order to ensure that overwriting occurs properly. Also, if all of the tweening properties have been overwritten (which would cause _gc to be true, as set in _init()), we shouldn't continue otherwise an onStart callback could be called for example.
//_ease is initially set to defaultEase, so now that init() has run, _ease is set properly and we need to recalculate the ratio. Overall this is faster than using conditional logic earlier in the method to avoid having to set ratio twice because we only init() once but renderTime() gets called VERY frequently.
if(self._lazy!==false){//in case a lazy render is pending, we should flush it because the new render is occurring now (imagine a lazy tween instantiating and then immediately the user calls tween.seek(tween.duration()), skipping to the end - the end render would be forced, and then if we didn't flush the lazy render, it'd fire AFTER the seek(), rendering it at the wrong time.
self._active=true;//so that if the user renders a tween (as opposed to the timeline rendering it), the timeline is forced to re-render and align it with the proper time/frame on the next rendering cycle. Maybe the tween already finished but the user manually re-renders it as halfway done.
}
if(prevTime===0){
if(self._startAt){
if(time>=0){
self._startAt.render(time,true,force);
}elseif(!callback){
callback="_dummyGS";//if no callback is defined, use a dummy value just so that the condition at the end evaluates as true because _startAt should render AFTER the normal render loop when the time is negative. We could handle this in a more intuitive way, of course, but the render loop is the MOST important thing to optimize, so this technique allows us to avoid adding extra conditional logic in a high-frequency area.
if(time<0)if(self._startAt&&time!==-0.0001){//if the tween is positioned at the VERY beginning (_startTime 0) of its parent timeline, it's illegal for the playhead to go back further, so we should not render the recorded startAt values.
self._startAt.render(time,true,force);//note: for performance reasons, we tuck this conditional logic inside less traveled areas (most tweens don't have an onUpdate). We'd just have it at the end before the onComplete, but the values should be updated before any onUpdate is called, so we ALSO put it here and then if it's not called, we do so later near the onComplete.
if(callback)if(!self._gc||force){//check _gc because there's a chance that kill() could be called in an onUpdate
if(time<0&&self._startAt&&!self._onUpdate&&time!==-0.0001){//-0.0001 is a special value that we use when looping back to the beginning of a repeated TimelineMax, in which case we shouldn't render the _startAt values.
self._startAt.render(time,true,force);
}
if(isComplete){
if(self._timeline.autoRemoveChildren){
self._enabled(false,false);
}
self._active=false;
}
if(!suppressEvents&&self.vars[callback]){
self._callback(callback);
}
if(duration===0&&self._rawPrevTime===_tinyNum&&rawPrevTime!==_tinyNum){//the onComplete or onReverseComplete could trigger movement of the playhead and for zero-duration tweens (which must discern direction) that land directly back on their start time, we don't want to fire again on the next render. Think of several addPause()'s in a timeline that forces the playhead to a certain spot, but what if it's already paused and another tween is tweening the "time" of the timeline? Each time it moves [forward] past that spot, it would move back, and since suppressEvents is true, it'd reset _rawPrevTime to _tinyNum so that when it begins again, the callback would fire (so ultimately it could bounce back and forth during that tween). Again, this is a very uncommon scenario, but possible nonetheless.
record=(vars!==overwrittenProps&&overwrittenProps!=="all"&&vars!==propLookup&&(typeof(vars)!=="object"||!vars._tempKill));//_tempKill is a super-secret way to delete a particular tweening property but NOT have it remembered as an official overwritten property (like in BezierPlugin)
if((killed||!vars)&&!_onOverwrite(this,overwritingTween,target,killed)){//if the onOverwrite returned false, that means the user wants to override the overwriting (cancel it).
returnfalse;
}
}
for(pinkillProps){
if((pt=propLookup[p])){
if(simultaneousOverwrite){//if another tween overwrites this one and they both start at exactly the same time, yet this tween has already rendered once (for example, at 0.001) because it's first in the queue, we should revert the values to where they were at 0 so that the starting values aren't contaminated on the overwriting tween.
if(pt.f){
pt.t[pt.p](pt.s);
}else{
pt.t[pt.p]=pt.s;
}
changed=true;
}
if(pt.pg&&pt.t._kill(killProps)){
changed=true;//some plugins need to be notified so they can perform cleanup tasks first
}
if(!pt.pg||pt.t._overwriteProps.length===0){
if(pt._prev){
pt._prev._next=pt._next;
}elseif(pt===this._firstPT){
this._firstPT=pt._next;
}
if(pt._next){
pt._next._prev=pt._prev;
}
pt._next=pt._prev=null;
}
deletepropLookup[p];
}
if(record){
overwrittenProps[p]=1;
}
}
if(!this._firstPT&&this._initted&&firstPT){//if all tweening properties are killed, kill the tween. Without this line, if there's a tween with multiple targets and then you killTweensOf() each target individually, the tween would technically still remain active and fire its onComplete even though there aren't any more properties tweening.
this._time=-_tinyNum;//forces a render without having to set the render() "force" parameter to true because we want to allow lazying by default (using the "force" parameter always forces an immediate full render)
if(val&&typeof(val)==="function"){//some properties that are very plugin-specific add a prefix named after the _propName plus an underscore, so we need to ignore that extra stuff here.
if(pt.f===2){
pt.t._applyPT.m=val;
}else{
pt.m=val;
}
}
pt=pt._next;
}
};
TweenLite._onPluginEvent=function(type,tween){
varpt=tween._firstPT,
changed,pt2,first,last,next;
if(type==="_onInitAllProps"){
//sorts the PropTween linked list in order of priority because some plugins need to render earlier/later than others, like MotionBlurPlugin applies its effects after all x/y/alpha tweens have rendered on each frame.
//provides a more concise way to define plugins that have no dependencies besides TweenPlugin and TweenLite, wrapping common boilerplate stuff into one function (added in 1.9.0). You don't NEED to use this to define a plugin - the old way still works and can be useful in certain (rare) situations.
//now run through all the dependencies discovered and if any are missing, log that to the console as a warning. This is why it's best to have TweenLite load last - it can check all the dependencies for you.
