drawing API vs. attachMovie: speed difference?

[metanet]

hi,
i'm wondering if anyone has doen any tests comparing the speed of rendering for "premade" MCs (attached from the library at runtime) vs. the exact same MC, drawn via the API at runtime (drawn only once, not per-frame).

at runtime i'm going to be moving, rotating, and scaling many polygons, and i thought i might as well check here to see if anyone has noticed any performance difference between API-generated and attachMovie()-generated shapes.

i COULD author these polygons beforehand and then simply attach them, however this would involve quite a bit of work and would only be worthwhile if it sped up rendering.


it seems a bit paranoid and/or stupid to think there's be a difference, however i've learnt that you never want to assume that things in the flashplayer operate sanely (for instance, array lookups take linear time instead of constant time.. i STILL don't understand that one).


the only thing i can think of is that shapes made in the library _could_ be processed during compiling into some kind of format optimised for the flashplayer's renderer. anyway..



thanks for any comments,
raigan
p.s - admittedly, this is something i could test myself, HOWEVER it's not a case of sheer lazyness that i post this -- there are several dozen different polygons, each rather complex, and i'd prefer not to spend several hours trying to recreate them all by hand, using a printout of their vertex positions

[>flashl!ght<]

> (for instance, array lookups take linear time instead of constant time.. i STILL don't understand that one)

What?

Also, I would think making the polygons via API would be much more time consuming than just authoring and attaching. Sorry, I don't know which is CPU-wise faster, but my gut feeling(not to be trusted) is that attachMovie would be faster, as it's on line of script.

[metanet]

hi,
thanks; i suppose i should have added that i'm not really asking about how long it will take to initally draw/attach the graphics (the API will probably be a lot slower), i'm more worried about (once the graphics have been drawn/etc.) if one will perform better than the other when altering _x,_y,_rotation via actionscript.

thanks though,
raigan
p.s - what i meant was that the length of time it takes to lookup an entry in an array is dependant on the length of the array and/or the number of the entry you're looking up. i.e

var temp = myArray[90];

will be faster than:

var temp = myArray[190];

[strille]

In my experience there's no speed difference, I've had the same idea as you, and the tests I've done in the past indicates that the drawing API generates the same type of vectors as the authoring environment.

Of course, if you don't draw the polygon in it's own movie clip to mimic an attached movie clip, the attached movie will be faster.

[lapo73]

p.s - what i meant was that the length of time it takes to lookup an entry in an array is dependant on the length of the array and/or the number of the entry you're looking up. i.e

var temp = myArray[90];

will be faster than:

var temp = myArray[190];

Could you explain this a little bit better? I've never noticed such differences

Lapo

[mentuat]

I would assume that once you have created an empty movieclip and dynamically drawn the shape in it, it would contain the same information and be treated the same as an attached movie with the shape drawn manually. They both have the properties of a movieclip and have to move the same number of vectors around.

other benefits of drawing on the fly that I can think of-

* little/no impact on your filesize
* can be 'redrawn' on the fly in necessary (elimates the problem with extreme scaling and rotation on pre-drawn vectors)
* can introduce random/math elements to make all shapes different from each other

[>flashl!ght<]

i dont think he's wondering if API generated MCs will be faster than attached MCs as much as he's wondering if creating an MC via frawing API is faster than attaching a movie.

[strille]

I'm pretty sure he's talking about rendering them, not the initial setup (done just ones from the sound of it). Generating MCs using the drawing API will almost certainly be slower than just attaching movie clips from the library.

[webgeek]

what i meant was that the length of time it takes to lookup an entry in an array is dependant on the length of the array and/or the number of the entry you're looking up. i.e
var temp = myArray[90];

will be faster than:

var temp = myArray[190];

This is most certainly NOT the case in languages like Java or C#. An array lookup in those languages (C/C++, and many others as well) is done via multiplying the size of the array object type (either data itself or reference/pointer based on the language) by the index position and pulling the object (or the value) from the specified memory address. This is a dramatic simplification because many languages do it a little differently with pointers/references as opposed to actual objects but thats the basic idea.

This means that if a reference to an object is 10 bytes long and the array is stored in memory at position 523 and has a length of 100 then memory positions 523 to 1523 are all reserved for the array references. In strongly-typed languages array sizes are NOT dynamic. You set it to a length at creation and it never changes. This means that to get the reference myArray[83], the runtime simply goes and multiples 83 by 10 (the reference size) and adds the arrays starting memory address to it. The position of the reference of 83 is located in memory at 1353. All of this means that array lookups are a constant-time operation in these languages.

If Flash is different, I would suspect it has to do with the losely typed nature. I don't know how ECMA script handles this so I can't say.

Please don't bash me for the midly inaccurate example. I just simplified this down to the logical process and left out the details (heap vs. stack, references to objects vs. primitives, etc.). Have fun!

[>flashl!ght<]

I'm pretty sure he's talking about rendering them, not the initial setup (done just ones from the sound of it).

after re-reading, yeah looks like it.

Generating MCs using the drawing API will almost certainly be slower than just attaching movie clips from the library.

agreed, so thats why i had said that since i misunderstood the question

so metanet, looks like we can assume:

1) creating MCs via the drawing API is more CPU intensive than attaching an MC
1b) plus coding the drawing will take more authoring time than building a linkage MC

2) a MC created via API & a MC created via attachMovie(pre authored) will behave the same at runtime

[metanet]

hi,
thanks everyone; i guess i can spend my time worrying about other stuff

flash _definitely_ takes linear time when accessing elements in an array. i suspect that this is because, internally, they're implemented as something like a linked list.. which would definitely make it easier to support all of the "array" methods like push, pop, etc.. i really wish the MM programmers would stop making it easy on themselves in exchange for performance.

anyway, after discovering this i stopped using arrays; if you use an object as a hash-table with integer keys, it takes constant time to access elements, i.e: var temp = myObj[10];
is just as fast as: var temp = myObj[835]

of course, you loose a bit of flexibility -- you can only iterate over the elements using a for..in, you can't get the next/previous element, etc. but for most of the stuff i was using arrays for, objects fit well.

aaaaanyway.. thanks for clearing that up.
raigan
p.s - mentuat: i'm not so sure that drawing a shape via the API will necessarily result in a smaller filesize, since i have to store vector information for the shape (i.e a list of vertices) which seems similar to what flash would store for vector shapes in the library. then again, tests seem to show that you're right for some reason.

[Ihoss]

webgeek, do you have any idea how I can make a dynamic list then? I'm using VB.net and I tried to put all the files in a folder in an array (or the name that is) but since its not dynamic that isn't easy.

oh, and in my 3d vector game (look to the left) I draw all the vectors every frame and it gets incredibly slow with a lot of vectors on screen, a lot slower than any flash animation would be. It might be due to the 3D calculations but I don't think so.

[Squize]

Wow, I'm shocked about the array access thing.
I've never ever come across that before ( In any language ).

How the hell can an object be quicker than an array ? Only in Flash

Thanks for sharing that titbit raigan, I've never seen that stated anywhere before.

Squize.

[lapo73]

flash _definitely_ takes linear time when accessing elements in an array.

I did a quick test, maybe it's just too stupid, however here's the code:

var aa, bb, i, item, t1, t2

aa = []
bb = []

// populate arrays
for (i = 0; i < 1000; i++)
    aa[i] = i
    
for (i = 0; i < 50000; i++)
    bb[i] = i

// Loop through aa
t1 = getTimer()

for (i = 0; i < 1000; i++)
    item = aa[i]

t2 = getTimer()

trace("1000 loops in aa took: " + (t2 - t1) + " ms")



// Loop through bb
t1 = getTimer()

for (i = 49000; i < 50000; i++)
    item = bb[i]

t2 = getTimer()

trace("1000 loops in bb took: " + (t2 - t1) + " ms") 

Basically the aa array is 1000 items only while bb is 50 times bigger. aa is looped from 0 to 1000 (so it should be faster) and bb (which has 50x elements) is looped in the last 1000 items (49000 - 50000)

I've run this test under Flash MX five times and this is the result I got on an Athlon 2.6ghz:

1)
1000 loops in aa took: 22 ms
1000 loops in bb took: 22 ms

2)
1000 loops in aa took: 22 ms
1000 loops in bb took: 22 ms

3)
1000 loops in aa took: 24 ms
1000 loops in bb took: 20 ms

4)
1000 loops in aa took: 21 ms
1000 loops in bb took: 23 ms

5)
1000 loops in aa took: 20 ms
1000 loops in bb took: 22 ms

I don't know how this behaves under FMX2004 however it doesn't look like it's a huge difference... can you provide an example that shows how array access speed is affected by its size?

[rabbitkiller]

Arrays slower than objects?
Well, nothing slows you down as attachMovie or duplicateMovie, any calculation delays are nothing compared to that...

[>flashl!ght<]

code:

---

m=100;



t1=getTimer()

for(i=1 ; i<=m ; i++){

	_root.attachMovie("object","object"+i,i);

}

trace((getTimer()-t1)/m);



t2=getTimer();

for(i=1 ; i<=m ; i++){

	x=23;

	y=54;

	distance = Math.sqrt((x*x)+(y*y));

}

trace((getTimer()-t2)/m);

---

test results, they are exactly the same.

code:

---

m=100;



t1=getTimer()

for(i=1 ; i<=m ; i++){

	_root.attachMovie("object","object"+i,i);

	_root["object"+i]._x=random(550);

	_root["object"+i]._y=random(400);

}

trace((getTimer()-t1)/m);



t2=getTimer();

for(i=1 ; i<=m ; i++){

	x=_root["object"+i]._x-_root["object"+i-1]._x;

	y=_root["object"+i]._y-_root["object"+i-1]._y;

	distance = Math.sqrt((x*x)+(y*y));

}

trace((getTimer()-t2)/m);

---

results: calc distance takes longer. math stuff tends to take longer than attach movie/duplicate movie, it has seemed to me

[EDIT] on a similar note, i have not been able to find a CPU pro faster method to do hittest, has anyone else?

[metanet]

hey,

..argh, my (hastily thrown-together) tests don't show any difference either.

i haven't got the original tests here, tomorrow i'll post them.
i'm positive there was a real difference between arrays and objects though.

damn it..
raigan

[webgeek]

webgeek, do you have any idea how I can make a dynamic list then? I'm using VB.net and I tried to put all the files in a folder in an array (or the name that is) but since its not dynamic that isn't easy.

Yup, your looking for an ArrayList. Look in System.Collections to find it. That's basically an array of objects that grows as you need it. Once your done with it, I recomend you cast it back to a pure array with arrayList.ToArray(type);
Have fun!

[metanet]

it would appear that my spurious claim was debunked

but i still haven't had a chance to get to the pc that has my test file... perhaps on monday. i suspect my test was screwed up though.
raigan