2 times in my life have I run into a conund…er, no that word sux. *ahem* …have I run into a challenge of whether to build a movie large movie clip or dynamically build it, showing only pieces at a time.
The first time was dealing with a timeline at work displaying a 24 hour period which fit on a grid. It was scalable, and as such, if you “zoomed” in your view of an hour, it could easily be 4000px + wide. Since it was dynamically drawn, this was cake to build, but we were unsure of the best way to display. Flash still “deals” with things not being displayed or offscreen with the exception of _visible. If you make something _visible = false, it helps a little, but you still have a lot more overhead when something is “there” and you wish to make a change, either moving something or modifying data. On the other hand, constantly rebuilding pieces of a movie clip constantly via minimal user interaction is resource costly as well.
It depends though; there’s a sweetspot as I’ve found in my tests throughout the last year from dynamic graphs to tile-based games. So, to prevent you from spending the time that I did, here are some results followed by some conclusions (hypothesis) on the best ways to get the most of out of your dynamic Flash movie clips’ performance.
<b>Results</b>
– dynamically drawing strokes vs a movie clip were significantly slower; even just one movie clip with a ton of stokes was significantly slower than one movie clip holding hundreds of instances. Additionally, building a “stroke” via a fill, helped a lot, but the optimal perceived performance by both my manager and I were a fill within a movie clip, which you then attach dyanically as needed.
– with the above, you lose resolution, even if your fills are on a positive (integer) pixel (x = 5 vs x = 5.68). Strokes are just drawing better regardless of their position while fills, if not exactly on a pixel and not exactly a certain pixel width will anti-alias themselves to the next pixel to emulate half-a-pixel, which looks blurry and non-exact.
– there’s always a number of movie clips on stage where things start to decline. By this, if your using many of the same components at once, things can potentially start to decline in performance at a certain number, and then quickly go downhill. This number – 1 is what I call the “sweetspot”. It’s where you get the best performance with the most instances. This is different for form type apps, or where you have many different types of movie clips/components on stage, and is more applicable to games and/or animation/transition intensive apps with non-stagnant interactivity.
<b>Hypothesis'</b>
– Fills are faster than strokes. Strokes display correctly more often than not while on a non-integer pixel coordinate while fills do not. If you have a choice of using fills or strokes, then use fills.
– If you can consolidate an interface element into a movie clip, then put it in one, then attach many instances of it dynamically rather than dynamically draw it. This is even faster than just drawing fills.
– If your doing simple benchmark testing on your own and experience a decline in performance, then mark the number of instances in which performance isn’t adversly unusable. If the maximum instances you’ll ever have is less or equal to that number, then your app can benefit from possibly having them already on the stage to prevent the needless attaching/removing of the movie clips.
– However, if the maximum number of instances is equal to and beyond what you’ll actually have in your app, then a progressive building/destroying mechnism is better because you can display an infinite number of instances and still have the same processor usage. At this point, it’s all about optimizing that solution.
A simple example of the former is the Accordion component in Flash Pro; it puts your contents on the pane, and keeps it there, regardless of how many panes you have.
The List however, draws the same amount movie clips regardless of the amount of data inputted, and simply cycles through the data, moving just it as necessary.
Both have pros and cons, but hopefully the loose guidelines above can help you save time in choosing an archetecture path.