This content has been marked as final. Show 12 replies
>>the following code eats so much processsing power
How do you know that (the code by itself doesn't)? I'm thinking: 'all the animations in my piece', well, it might be the combination.
Lot's of _alpha settings? Everything on depths close to each other (used getNextHighestDepth())?
Your'e right the code snippet on it's own doesn't cause any problems, however when I add it to the rest of my site it causes problems.
The page in question only has a fairly basic animation that plays on a mouse rollover, however if you add that code snippet it slows the rollover animation down. However it is not too bad with so few lines drawn, but I was hoping to increase the nos of lines, but the more lines the slower the animation.
...also not using getNextHighestDepth();
Anyway just thought someone might have had a problem with drawing lines?
thanks for the response. J
Can't replicate the problem. Post a link to the fla?
You can download the fla from:
The code above works fine, but if you up it to around 400 lines drawn opposed to the code above that only draws 9, is when the errors kick in... the following code draws around 400 lines:
createEmptyMovieClip ("curveLine", 3);
If you have any simple animation playing on the stage at the same time as the code snippet it will play slower.
Like I said it isn't too much of a problem, I will just use less lines although if you know why more lines looks better. Thanks for your help J.
See what you mean although I just see a slight decrease in performance when drawing 400 lines. The problems begin when I draw about 700 lines (so it seems to be tied to processor speed). Tried several things, like splitting it up in several clips, setting the _alpha of the lines to 100, using depths like 1000, 2000, 3000 but at one point performance slows down and when it does it's a dramatic decrease. No, don't know why exactly, I never have drawn that many lines. Someone else?
flash appears to keep track of the line segments in each movieclip used with the drawing api. as the number of movieclips+line segments increases the cpu bogs down.
to remedy, periodically use the draw method of the bitmap class to draw the current movieclip that's the target of the drawing api. remove or replace the current movieclip and continue drawing.
Thanks kglad for picking this one up.
:) you're welcome.
Thanks guys for your responses, can I just clarify, as I'm not fully understanding your answer kglad, basically, to remedy the problem... don't go crazy with the number of lines drawn in a movie clip, and when you do use it remove it from the stage to stop it from slowing other things down?
thanks again. J.
well, i'm not sure of your setup so i can't give you a specific remedy.
however, the most common setup is one movieclip with a linestyle defined and various moveTo(), lineTo() and curveTo() methods applied to that movieclip. as the number of those methods increases performance of the swf decreases.
generally, all the lines and curves are needed and cannot be removed without diminishing the usefullness of the swf. if that last sentence is not true, the solution is even easier and no bitmapdata class is needed.
so, assuming you need a lot of the lines/curves that are being created by the drawing api, what you do is to periodically transfer the graphics to a bitmap and remove or replace the movieclip that contained all those lines/curves.
it's that movieclip that's causing the problem. flash seems to keep track of every line and curve even if you stop drawing and enable the cacheAsBitmap property of the movieclip and use a different movieclip as the target of your drawing api.
anyway by using the bitmapdata class you can preserve the graphics created by the drawing api. you can then free-up all the resources that the movieclip was hoarding by removing or replacing your movieclip and continue using your drawing api with another movieclip until it too starts to impact performance.
at that point just preserve the graphics again to the same bitmap, replace or remove the movieclip etc.
thanks alot kglad.