converting tweenmax to frames [SOLVED]

[maurik]

hello there

 

is there any possibility to convert tweenmax animation into frames?

 

most of my animations are done with tweenmax, and a lot of them don't depend on any variable, completely static. i noticed that even basic animations done to small objects sometimes make CPU peak. i thought that perhaps as frames they would take less. is it true? is it possible?

 

 

thanks,

michael

[GreenSock]

Well, not only is converting the ActionScript-driven tweens to frames impossible (I assume you mean creating MovieClips with timeline tweens automatically from your TweenMax code), but it almost surely wouldn't help you at all performance-wise. The VAST majority of the load on the CPU has to do with graphics rendering. Literally like 100 times more than the ActionScript execution (actually probably more). So you could rebuild the tweens on the timeline, but it would just make your animations less flexible and could even make them less fluid. ActionScript-driven tweens have lots of benefits:

 

1) They're dynamic and easy to change during runtime (I know this isn't a big deal to you right now)

 

2) They're more dependable in terms of timing. If you tell a TweenMax tween to take 2 seconds, it will take almost exactly 2 seconds not matter how crappy of a CPU the user has. However, if you use timeline tweens, they're forced to play every frame, meaning your 2-second tween may end up taking 3 or 4 seconds if the computer is slow.

 

3) You can slow down TweenMax tween by altering their timeScale and it will interpolate perfectly smoothly whereas timeline tweens would get very jerky/stuttery if you tried the same thing because they have a fixed resolution (number of frames).

 

So in summary, I can't imagine a single up-side to rebuilding the tweens on the timeline other than maybe if you need to visually work with them during authoring time. If you want to improve performance, focus on the graphics rendering. Minimize the areas of change that the Flash Player must render. Minimize the amount of overlapping alpha effects. Avoid complex vector artwork. Avoid masks if possible.

 

Hope that helps.

[maurik]

Ok.

would this be quicker -

 

add a parameter to the vars object - record:Boolean = false. if true, on tweenlite's ENTER_FRAME event, along with updating the properties of the tweened object, it also stores all the changed properties in an array (could be even a single property).

the array's length corresponds to the number of frames the tweening took, each object in the array contains the properties of the tweened object as they were at that frame.

thus you create a library of recorded tweens, and to replay a static tween you do something very similiar to creating a new tween instance, only skipping all the calculations.

logically, this should be quicker to execute.

 

if i have at realtime about 50 tweening things that depend on a lot of non changing variables and perhaps a complex trigonometric calculation (that once calculated doesnt change),

would i not benefit from the fact that they dont have to calculate nothing, but simply read from array?

[GreenSock]

There are several downsides to that approach:

 

1) The way you'd need to store the values in an Array based on the property that is being tweened would actually take about 10x longer to look up compared to doing the simple calculations inline. The calculations in the tween that get executed on every frame are very simple, like s + c * r. I ran a test in AS3 and it was more than 10 times faster to just do the calculations on every frame.

 

2) Memory. You're storing the property values for every frame. This shouldn't be a big issue for a few tweens, but if you do a lot, well, obviously it starts to eat up a good chunk of RAM.

 

3) It assumes the frame rate will remain consistent every time you play the tween (at least if you're doing time-based tweens). Remember, the Flash Player can bog down during complex rendering routines and the garbage collection routine runs at random times requiring CPU power as well, so it isn't reasonable to assume the frame rate will always be consistent.

 

Again, I think you're focusing too much on the code, thinking that it's slowing you down whereas there's a MUCH, MUCH higher probability that the graphics rendering accounts for 99%+ of the CPU usage. In other words, let's say that you optimized the code so that it ran 500% faster than the old code (virtually impossible to get that kind of performance gain in the code, but let's just assume so for the sake of argument). If the original code was only accounting for 1% of the load on the processor and graphics rendering was the other 99%, that means the net effect of that 500% performance boost in the code is about 0.8% of the processor load. You wouldn't really notice any difference at all.

 

In theory, your idea has merit especially if you're comparing an Array lookup to a very complex calculation or function call, but the practical reality in this case gives you the exact opposite result.

[maurik]

I see.

well, thank you very much for clearing that out.