as3 faster?? i see the opposite

[patrickjv]

Made in AS2, 24 fps
http://www.patrickjansen.net/test/___as2.html
Made in AS3, 24 fps
http://www.patrickjansen.net/test/___as3.html

The AS2 animation plays faster then the AS3 animation.
They're relatively the same in structure, so it boggles me why as2 plays better then as3.

weird...

[senocular]

It almost looks like the frame rate is different (though they appear to be set the same). Can you provide the FLAs?

[joshchernoff]

I'v seen a small but bigger then previous versions delay when you use gotoandplay to make a looping animation that loops to a non entry frame

ex...
you play a movieclip at the last frame you add gotandplay(5); so that your not looping from what could be a intro n to the movie clip.

for the most partwhat I'v seen is in frame and time line code for animation is worse yet strict OOP via class structures are faster.

[senocular]

yeah if you're doing timeline tom foolery, you could see a hit there; AS3 was not designed with the timeline in mind - its primary focus was on Flex (with what AS3 was released with) which has no timeline. The timeline additions for Flash were kind of an afterthought and you won't see the same behaviors which could affect your performance.

[patrickjv]

I indeed have timeline 'animation' so that might be it. Notice that it's not because of stubborn choice. I have this because I'm trying to make it as easy as possible for a user/customer ->

1) Up till now I offer (commercial) components installed by .mxp file.
2) a user/customer drags a component from component panel to stage of their own movie
3) ALL contents required need to be added to users .fla (or folder where .fla is saved).

When using .as class files, the above won't work. The required .as files are not added and the components won't work in steps above. I tried.

That's my main reason so far for using timeline scripts. And also added an extra layer to the component with needed library items. This layer is not really used but otherwise it will also mean some required library content is not added to a users .fla file.

I have been considering non-.mxp files, but .mxp installed components are sooo much more user friendly to a customer then having tons of steps for copy-pasting between .fla files and folders.
Probably I'm going to test now to see if .as based scripting is faster. Guess it probably will

Aside from letter animation, many components I made also have shapes and 'cartoon-like-objects' and 'timeline Movieclips' so these "HAVE TO" be added as mc-played-timeline ... something also to keep in mind
( see e.g. "clown", "dragon" and "ufo" effect on patrickjansen.net/components/demos/elite/ )

Senocular, since it's commercial work in progress, I prefer not posting .fla's publically but for your eyes only I can provide them. Later I'll need AS3 beta testers anyway.

[dthought]

I'd say it's because the AS3 example is using "antialias for readability" whereas the AS2 example is using "antialias for animation".

Problem solved? :D

[patrickjv]

nop, both have 'antialias for animation', one of the first things I checked ;)

[pingnak]

Rather than profiling two clips at a fixed rate of 24 FPS when they can obviously go far faster, you might want to crank the frame rates as high as they can possibly go and see if they can keep up with each other. I cranked the AS2 version up to 120FPS and it went much faster. This tells me that they can't possibly look/behave differently until you crank up the speed.

At runtime, you can set the AS3 frame rate to 1000 and see if it can keep up with that with some simple real-time clock based profiling tools. Just keep a running average of the frame rate. It would probably do hundreds of FPS in AS3, while in AS2 it will top out at 120FPS (the maximum you can set with the UI), if it can reach that. It looks pretty trivial, so I bet it *does* at least nearly reach 120FPS in AS2.

In AS3, from any DisplayObject (i.e. Sprite, MovieClip)...
stage.frameRate = 1000;

Whatever bug you're working around in AS2 with "eval", you might also want to replace with native code in AS3. The compiler certainly can't optimize around that, and you'll find that AS3 is far more stable.

And finally, make SURE you're running with the release mode AS3. With Flex, I find that after a debug session, the debug version of the intepreter remains linked/associated to everything, and buggers profiling until I run the release mode once.

[patrickjv]

I have a hunch it must be due to what senocular said, use of timeline(s). I think so because I tested without font textfield and with a simple square instead and it still plays slower, so I don't think that font use if the cause. And scripts 'setup'/'structure' is about the same in as2 and as3.

SENOCULAR; what I don't understand is how to use "no timeline". I use a 3frame loop in component and a say 12 frames loop in childs. Even using class .as files I'd be using keyframes anyway calling upon script(s) defined in the .as, wouldn't I? Would that make any difference???

[Dazzer]

Maybe when they said AS3 is Faster, they meant that it can do calculations faster.

[senocular]

calculations are what is faster (thats AS). Screen rendering hasn't really changed. But that doesn't mean it should be slower either.

@patrickjv: it depends on how that timeline is set up. Can you provide a simple example that only shows the use of your timeline(s) and how navigation would be handled through those frames?

[ven]

I migrated a project from MX2004 into a Flash Components/Flex 2 project, where i copied timeline animations (buttons etc.) into AS3 swc's. There i found some of the buttons drasticly go down in fps performance, while others worked alot better. I went in and out of the animations, copied and broke them down, compared them to eachother and even swapped the graphics framebyframe, without ever finding the reason for why.

In the end everything got smooth, without ever really knowing why, nor remembering how to provoce the error into appearing.

Just thought i should mention, Flash CS3 seems to have some issues when reusing preCS3 timelines.

[senocular]

In short, goto commands tend to be "delayed" in AS3 (they're queued until the next frame), and you might see an extra frame thrown into your animation when using them. This could account for the slowness in your animation and I'm already working on getting this addressed.

[Dazzer]

All Hail Senocular!
- kowtow -

[dthought]

nop, both have 'antialias for animation', one of the first things I checked ;)

Are you 100% sure? When I looked at both animations: the AS2 example had antialiasing reminiscent of the crap AA for Animation option - it looked quite crunchy once it finally stopped flying about (but it is faster).

However, the AS3 example, when it stopped (albeit on a 45 degree angle and semi-transparent) its AA was much, much smoother - reminiscent of the AA for Readability (and hence slower). I'm wondering if perhaps it's gotten itself confused somewhere and forced AA for Readability in the AS3 example.

Can you double check this, perhaps?

[patrickjv]

@dthought:I'm sure, for the AS3 model I opened a AS2 .fla and reused the library item so it MUST be the same.

@senocular: About the goto actions. I can now confirm with 100% certainty you've been right on the spot and that that has been the critical factor. I have implemented ALL scripts into the first frame and use functions with a main counter variable to call those scripts/functions which I used to have in frame loops.
Result is like animation is almost going twice as fast visually.

It's not the solution I'd hoped for, since it will make it a LOT more difficult if customers would want to make custom modifications to the components but at least I have a properly playing model.

TNX!

[senocular]

The way AS3 handles goto statements is a bit different than AS2. In AS3 the statements are queued and then executed at the end of the current frame (or the beginning of the next - somewhere in there) unlike AS2 which immediately played those frame upon calling the goto statements.

For gotoAndPlay, AS3 does a kooky thing where it treats the goto time frame as a time frame of the new destination frame. This means the time spent on the goto frame is 2 times the norm because its sitting there for both the goto frame and its own frame time.

I actually have a bug written up about this, so its likely this will be fixed in FP10 or something. In the mean time, I've used a class that *kind of* gets around this, but behaves a little differently than the normal goto commands. I can post it if you want, though I don't know how robust it really is.

[Dazzer]

The way AS3 handles goto statements is a bit different than AS2. In AS3 the statements are queued and then executed at the end of the current frame (or the beginning of the next - somewhere in there) unlike AS2 which immediately played those frame upon calling the goto statements.

For gotoAndPlay, AS3 does a kooky thing where it treats the goto time frame as a time frame of the new destination frame. This means the time spent on the goto frame is 2 times the norm because its sitting there for both the goto frame and its own frame time.

I actually have a bug written up about this, so its likely this will be fixed in FP10 or something. In the mean time, I've used a class that *kind of* gets around this, but behaves a little differently than the normal goto commands. I can post it if you want, though I don't know how robust it really is.

How about forcing it to go to the next frame by using nextFrame? Say adding an EnterFrame listener to all objects that require it, and just put

e.target.nextFrame();


would that work? lol

[senocular]

How about forcing it to go to the next frame by using nextFrame? Say adding an EnterFrame listener to all objects that require it, and just put

e.target.nextFrame();


would that work? lol

That's an intersting idea. My current workaround uses gotoAndStops to simulate normal playback but it might be possible to use nextFrame during the next onEnterFrame of the gotoAndPlay to try to force advancement. One problem is that nextFrame stops the playhead... and its possible that attempting to do that might cause the double-up to happen just on the next frame instead.

I'll play around with it a little.

[senocular]

nope. As I thought, the delay was just offset a frame. I tried a few combinations of nextFrame, play, gotoAndPlay, and gotoAndStop, but nothing got around the gotoAndPlay doubling-up.

[patrickjv]

hmm.. if it's a bug, then it's dubious what best to do
1) create 1frame scripts and be sure all works fine now and in the future
2) wait for a fix before I release updates of my commercial stuff

..first would be a gigantic amount of extra work, i have over 200 animations to do
..second would be uncertainty

is the class-workaround you mentioned 'easy to implement anywhere'?

[senocular]

is the class-workaround you mentioned 'easy to implement anywhere'?

Its a MovieClip base class you just extend (or specify as a base class in the library). It overrides the goto commands and instead uses them to handle frame navigation with gotoAndStop. The difference is that you have to call goto statements ahead one frame. so for example if you want to play frames 1, 2, 5, 6... you'd have to put the gotoAndPlay(5) on frame 2 and not 3. Its kind of hacked that way, but at least gotoAndPlay statements don't result in a two frame goto frame.
package {

import flash.display.FrameLabel;
import flash.display.MovieClip;
import flash.events.Event;

/**
* The MovieClipNavigator class attempres to provide
* a frame navigation experience more along the lines
* of that available in ActionScript 2. More specifically
* it removes the frame delay experienced when using
* gotoAndPlay with ActionScript 3. Because of the nature
* of scenes, they should be avoided when using
* MovieClipNavigator.
* <br />
* One difference with the way MovieClipNavigator
* instances work when compared to ActionScript 2 is
* that goto statements need to be called on the frame
* prior to the frame receiving the navigation. The frame
* with the goto statement will be run normally and the
* following frame will be run as the frame specified
* in the goto statement.
* <br />
* Added to MovieClipNavigator instances is an additional
* isPlaying property that indicates whether or not
* the instance is playing (true) or stopped (false).
*/

public dynamic class MovieClipNavigator extends MovieClip {

private var _frame:int = 1;
private var _isPlaying:Boolean = true;
private var _queued:Boolean = true;
private var labelHash:Object = new Object();

/**
* Returns the current playing state
* of the instance
*/
public function get isPlaying():Boolean {
return _isPlaying;
}

/**
* Constructor - usually extended to add
* functionality to sublcasses or used as
* base class for library movie clips.
*/
public function MovieClipNavigator(){
super();
super.stop();
buildLabelHash();
addEventListener(Event.ENTER_FRAME, navigationHandler, false, 0, true);
}

private function buildLabelHash():void {
// build label hash from defined labels
var labels:Array = currentLabels;
for each (var label:FrameLabel in labels) labelHash[label.name] = label.frame;
}

private function navigationHandler(event:Event):void {
// auto increment if not about to play
// a queued frame and is playing
if (!_queued) {
if (_isPlaying) _frame = (_frame == totalFrames) ? 1 : _frame + 1;

// frame is no longer queued
}else _queued = false;

// go to new frame if not there already
if (_frame != super.currentFrame) super.gotoAndStop(_frame);
}

private function setIsPlaying(b:Boolean):void {
if (!_queued) _queued = true;

if (b == _isPlaying) return;
_isPlaying = b;

// only have navigationHandler running
// if instance is playing
if (_isPlaying) addEventListener(Event.ENTER_FRAME, navigationHandler, false, 0, true);
else removeEventListener(Event.ENTER_FRAME, navigationHandler, false);
}

// override currentFrame
public override function get currentFrame():int {
return _frame;
}
// Override navigation methods
public override function gotoAndPlay(frame:Object, scene:String = null):void {
_frame = (frame is String) ? int(labelHash[frame]) : int(frame);
setIsPlaying(true);
}
public override function gotoAndStop(frame:Object, scene:String = null):void {
_frame = (frame is String) ? int(labelHash[frame]) : int(frame);
setIsPlaying(false);
}
public override function nextFrame():void {
var currFrame:int = super.currentFrame;
_frame = (currFrame == totalFrames) ? 1 : currFrame+1;
setIsPlaying(false);
}
public override function play():void {
setIsPlaying(true);
}
public override function prevFrame():void {
var currFrame:int = super.currentFrame;
_frame = (currentFrame == 1) ? totalFrames : currFrame-1;
setIsPlaying(false);
}
public override function stop():void {
setIsPlaying(false);
}
}
}

I haven't used it a terrible bunch, so its possible it may break down in some circumstances.