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.