Blog

<a href=”http://www.mediatemple.net”>Mediatemple.net</a>, my hosting provider, orignally had their website done in HTML and these phat CSS based menu’s. This morning, looking to see how to get my email to work with Outlook Express, I noticed their menu is now done in Flash, as is the frontpage.

I don’t see the point in doing the front page elements in Flash other than cool factor, but I do see the point in doing the menu; with all the issues I’ve had with getting CSS + JS to work on multiple browsers and platforms (with such a simple thing), I’m thinking their logic was that it will always look the same. Anyway, I like it.

I don’t read much. From disregarding instruction books on my Nintendo games to only touching the new <a href=”http://www.macromedia.com/devnet/mx/flash/”>DevNet</a> articles when I want confirmation in my hard won beliefs. I feel I learn better through doing.

So, I figured I’d give the DataProvider a try with the new components in F-two-Fo (F24/Flash 2004). I breifly scanned over the intructions as I couldn’t get a simple List to update with my DataProvider’s information. I liked the simple way of setting it’s property to the DataProvider instance, but… it still didn’t work. Since they documented modelChanged, I thought maybe I had to broadcast it myself, or maybe subscribe the List as a event listener manually; no dice. After actually reading, it seemed I was doing everything correctly.

So, I naturally asked <a href=”http://www.erikbianchi.com/”>Erik</a>; if I can’t figure something out, and still can’t after actually RTFM, Erik is my first choice of help. After discussing last night’s <a href=”http://www.dayofdefeat.com/”>DoD</a> excursions while Erik pounded away, he reached the same point of “wtf” that I did. The DataProvider.as file was kind of whack too.

Erik kept mentioning that he read and interpreted the docs as saying the DataProvider was nothing but an API; basically just an interface not actually holding any data (because the Array’s worked). I then re-read the 2nd paragraph if the List’s dataProvider description (I think that’s where it was). It turns out that the DataProvider simply extends the Array’s prototype so all Array’s now have the DataProvider methods (addItem, removeItem, etc). We tried it and it worked.

Why does weird shiot always happen on Friday’s?

So, in conclusion, DataProvider used to be a class in which to hold all of your data. Now, it’s just a (don’t know the pattern name) an API that’s added to Array’s. So you create an array, but use the DataProvider methods on that array.

Uh, yeah. If this is already covered on DevNet, whoop-pu-dee-dooooooooo…

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.