eigenface

Thanks, I'd done that in the past, but recently I've been trying not to put any code in on the timeline. I guess one line wouldn't hurt.

I guess potentially, since I'm tweening from frame 1 to totalFrames instead of from frame 0 (which doesn't exist) to totalFrames, I should do: clip.gotoAndStop(1); TweenMax.to(clip, clip.totalFrames - 1, { frame:clip.totalFrames, useFrames:true }); This that right?

I often want to play through a MovieClip once and then not loop again. Flash appears to have built-in behavior for this, because you can use the right-click menu on a running swf to uncheck "loop", and then the MovieClip will stop once it gets to its last frame. However, I cannot find any way to access this behavior using actionscript. The best I can do is listen for enterFrame events and check if currentFrame == totalFrames on each and every frame, then stop the clip and remove the listener on the final frame. Am I missing something? Is there a better way? The reason I bring this up here is I've been using TweenMax as an alternative, like so: clip.gotoAndStop(1); TweenMax.to(clip, clip.totalFrames, { frame:clip.totalFrames, useFrames:true }); Will this produce exactly the same result as listening for enterFrame events and stopping the clip when currentFrame == totalFrames? Or is there some timing/delta-frames weirdness with FramePlugin and useFrames?

I wonder how difficult it would be to remove the enter frame event listener that updates the tweens, when there are no more tweens to update. As I understand, the event listener is added when the first tween is instantiated, and never removed, continuouslybeing triggered by enter frame events from that point on, even if there are no tweens. You wouldn't have to search through the whole tween/timeline hierarchy to determine if there are any tweens to update, you could just keep a tween counter variable, the same way you cache other state variables instead of calculate them each time. When a tween is enabled, if the counter is 0, you add the event listener, before incrementing the counter. When a tween is disabled, you decrement the counter, and then if the counter is 0, remove the event listener (and possibly do a garbage collection pass.) What do you think?

Now there's TweenMax.killAll(complete=false, tweens=true, delayedCalls=true)

It looks like every 60 frames, references to dead tweens are removed so the garbage collector can free the memory. The optimal period of time between when dead tweens are referenced depends upon how tweenmax is being used, i.e. how many tweens are being created. Would it be possible for the user to adjust this 60 frames? Actually, figuring out the absolute best number of frames between dereference passes is difficult, and may not offer much performance benefit over just using 60. I'm not sure. What I am pretty sure about is sometimes it would definitely be better have control of exactly when the dead tweens get derefernced. Garbage collecting a large number of objects can make the flash player frame drop momentarily or skip, breaking up an otherwise smooth animation. I've often wished I could tell the garbage collector not to run for a certain period of time (while the animation is going on), then tell it to run immediately afterward (while nothing is animating), then tell it not to run while the next animation is going on, etc. I can't directly control the garbage collector in flash, but I can prevent it from having a reason to run by not dereferencing any objects. With tweenmax, you could potentially allow me to do this, at least for tween objects. You could have functions to enable and disable periodic dead tween dereferencing, and also a function to immediately dereference all dead tweens. I know when my app can afford to have the garbage collector run and remove dead tweens, and when I'd prefer not, so the animation won't skip. Would it be possible to add a function to enable and disable periodic dereferencing, and a function to immediately dereference all dead tweens? And maybe even a function to set the frequency of the periodic dereferencing that goes on.

No problem. The import statement in LiquidStage for com.greensock.data.* is down by the definition for internal class LiquidItem.

I notice LiquidStage imports com.greensock.data.*, even though it does not use any classes from this package. LiquidWrapper similarly imports com.greensock.easing.* without any need. I noticed this because I had to create empty easing and data folders in order to get the liquid layout classes to compile. Not a big deal obviously, but there's no need to import those packages if they're not used.

You're welcome. I have another one, if you want to further clean things up. You got rid of killAllTweens and killAllDelayedCalls in favor of keeping killAll public. You could also get rid of pauseAll and resumeAll in favor of making changePause public. In both implementations, the first 2 methods simply call the 3rd. Although, changePause is an odd method name. I often use a convention like enableInput(enable:Boolean = true) where the method name is "do something positive", and by default it does just that - enableInput() - or you can pass an argument to have the opposite effect - enableInput(false). Similarly, in place of pauseAll, resumeAll, and changePause, you could have a single method pauseAll(pause:Boolean = true, tweens:Boolean = true, delayedCalls:Boolean = true)

Glad to see pauseAll is back. That makes my life easier. I noticed something odd, though. For killAll, tweens and delayedCalls both default to true, but for pauseAll and resumeAll, tweens defaults to true and delayedCalls default to false. I'd prefer if tweens and delayedCalls both default to true for all 3 methods. TweenMax has the word "tween" in its name, but it is de facto both a tweening and timing utility, and "all" should mean "all".

It's confusing for stopAll to control paused - pauseAll should control paused, or stopAll should control stopped. In isolation, changing pauseAll to stopAll confuses as much as it clarifies. To my taste, paused and stopped are both cumbersome because they're negative - there should be a property called "playing" instead. Ideally, MovieClips, timelines, and tweens should all share naming conventions. They should all use forms of "play" and "stop" for method and property names - resume and resumeAll should be play and playAll, restart should be replay, etc. If you don't want to go that route, it seems okay to use different naming conventions for MovieClips/timelines versus tweens - MovieClips/timelines stop and play, but tweens pause and resume. The idea of tweening is conceptually distinct from the idea of grouping or sequencing tweens.

I guess pauseAll has been renamed to stopAll. That one just seems pointless to me. The paused property is still called "paused".

Thanks, that makes sense.

Does it help if I call an init function in the constructor and put all the constructor code in init instead?

Sounds good to me.

Ok, I guess you're on top of it then. Pre-pool-hype, I had done my own tests and noticed object creation is slow, so I try to reuse instances where possible. This is probably more of a concern when the object creates other objects in its constructor (and so on), which happens a lot for library items designed in the GUI - all the children (and grandchildren, etc) have to be created.

Looks like in the latest v11, killAll has been made private. I use that for everything, all of which would now have to be changed. It's a very convenient method for projects with both tweens and delayed calls when you just want to reset the entire state and start over. For whatever it's worth, here's 1 vote for keeping killAll public.

Have you thought about using object pools for tween/timeline instances? As you know, in addition to function calls, object creation is slow in actionscript. More importantly, the frame rate can stutter when the garbage collector runs. I believe your platform currently deletes references to unneeded instances and leaves them for the garbage collector. Maybe it would be better to keep them in a pool, wipe their state, and reuse them later. There could be a default pool size which the user could change, populated when the class-level init happens, or maybe not populated at all unless the user calls an initPool(size:uint) method. Tween/timeline instances would be drawn from the pool when methods like TweenLite.to are called. Calling new TweenLite would still create a new instance, of course - TweenLite.to would also if the pool is empty. Not sure if object pools are necessary for you platform, just something to think about. Also, I wonder how difficult it would be for me to implement a separate object pool utility for tweens/timelines. It could potentially get complicated because of the references between tweens and timelines. I guess I'd want to keep a stopped timeline full of pool tweens, which I'd reparent and reinitialize when I needed them.

Also, I just updated to the most recent version of v11 before trying this.

I've sent it. My custom PinPoint defines the image as its parent, unless I'm not understanding what you mean by parent.

The layout I've put together with LiquidStage renders differently depending on whether I open the swf by compiling with CS3, double-clicking on the compiled swf, or opening it with Firefox. I have an image, a horizontal grey bar behind the image, and a white background box. I want the image to scale with a constant aspect ratio as the stage is resized. I have a horizontal grey bar sitting behind the image at the same y-value as the image with the same height as the image, which I want to stretch vertically so it's always the same height as the image, whatever that height may be as the image scales. I also want the grey bar to stretch horizontally so it reaches all the way across the stage, whatever width the stage may have. The white box should always stretch to fill the entire stage. Here's my code: stage.tabChildren = false; stage.showDefaultContextMenu = false; stage.scaleMode = StageScaleMode.NO_SCALE; LiquidStage.init(stage, 1260, 735, 0, 0); var wrapper:LiquidWrapper = new LiquidWrapper(image, NaN, NaN, LiquidWrapper.ALIGN_TOP, LiquidWrapper.ALIGN_LEFT); LiquidStage.stretchObject(wrapper, LiquidStage.TOP_LEFT, LiquidStage.TOP_RIGHT, LiquidStage.BOTTOM_LEFT); var pinPoint:PinPoint = new PinPoint(image.width, image.height, image); LiquidStage.stretchObject(greyBar, LiquidStage.TOP_LEFT, LiquidStage.TOP_RIGHT, pinPoint); LiquidStage.stretchObject(whiteBox, LiquidStage.TOP_LEFT, LiquidStage.TOP_RIGHT, LiquidStage.BOTTOM_LEFT); This works correctly when I compile from CS4, but when I double click on the swf, the grey bar is always slightly taller than the image, and when I open with Firefox, the grey bar is a lot taller than the image. Is there a way to keep the bar the same height as the image no matter how I open the swf?

I'm dismayed the results of this poll so far do not support GoASAP. I can certainly see why people want TweenMax to run as fast as possible, but I can also see great value the ability to make an integrated tweening and physics engine, and I'd prefer to use TweenMax for the tweening. Maybe this poll isn't framing things in the best way. Ideally, TweenMax would remain TweenMax, and there would also be a separate GoTweenMax. I understand if this entails too much work. Personally, if I have to chose, I'd prefer GoTweenMax over TweenMax, because TweenLite already exists for those applications that require high speed above all other features. Not to mention, the speed difference is only apparent when you use an obscene number of simultaneous tweens. I'm curious, how real is the need for a tweening engine with the additional features TweenMax has over TweenLite, plus the slight additional speed TweenMax has over say HydroTween? How many projects exist which simply cannot make do with TweenLite, and also have the gargantuan number of tweens necessary to take advantage of this slight speed advantage of a TweenMax NOT built on GoASAP? Maybe I'm biased for my own work experience, but I have a hard time imagining many situations like that. I have a much easier time imagining all the exciting possibilities of using TweenMax's concise, intuitive syntax and powerful features seamlessly with a physics engine or 3D renderer. I guess in my mind, TweenLite will take care of those with a need for blistering speed and small file size, while TweenMax should look to the possibilities of the future, which includes GoASAP.