Werkin’ on a project this weekend where separating the audio to a level wasn’t an option because I needed the code to be simple. It was a simple slideshow with synced (streamed) audio, and the deadline was tight. The problem, though, was each test movie took a long time. Eventually, I’d change the audio compression to RAW just so the compile times were better, but a 4 meg mp3 even at RAW compression still took about 10-20 seconds on my 800 p2.
I managed to get the main interface and all it’s parts to be consolidated into one SWC. This was really nice as I could reuse it in other movies simply for it’s interface, since unless you setup event listeners, it didn’t do anything.
Frustrated post project on how to make things more efficient, I tried to do some SWC tests this morning with audio. First thing I forgot was that SWC’s, are in essence, SWF’s. Flash will merge them with the SWF your compiling too. Since an MP3/Audio file that is merged with the timeline, and only the timeline won’t export into your final movie. Thus, it gets compressed twice. So, I set its linkageID, and tried that. Even though the same 1 meg SWF went from 3 minutes (mp3 64 bit Best) to 3 seconds, the audio kept getting recompressed. Not really sure why, since I set the audio via the mp3 itself in the source FLA, and didn’t have override audio compression settings checked in the Publish settings.
At any rate, what I did conclude is that for anything I can consolidate into an SWC greatly expedites my development time, whether for programming projects or others. Besides, most non-programming projects have a plethora of library media of graphics, bitmaps, text, ect, and it’s nice to have just one symbol to deal with. The time savings in compiling from using SWC’s for non-programmatic content is definitely worth investing time in to learn and test them out. Multiply 3 minutes by how many times I typically do a test movie in a typical development session, and then change that number to 3 seconds… you can see how much more efficient you can get if you implement this solution across the board.
Not trying to pick on you, but Flash has us spoiled as far as compile times go. Having to wait 30 seconds for a movie to compile is nothing compared to having to wait hours.
It’s very common for shops to check out code in the morning, work all day, and then check code back in and re-compile the application overnight because the compile takes that long.
For example, the AS Compiler I’m working on, which is more or less just a lexer/parser right now (and supports syntax checking) takes over 14 minutes to compile. Because of this, I’m forced to think about the changes I make for every build instead of trying something, see if it works, trying something else, see if that works, etc.
The slow compile times lead to better thought out code, to generalize. Of course, it oculd also lead to buggier code bceause people are less willing to tweak things here and there and spend hours rebuilding just to, say, get a label to move 3 pixles to the left.
Double edged sword. What was my point again?
You know I love you, so to throw a monkey wrench in your points, by having more strict typing, that slows down compiling… I mean.. come on.
Besides, you make a great point. I come from the background of 3 day to 2 week deadlines. It’s all about the deadline, about making sure it looks or works just right for the client, and quickly. Thus, my paradigm of thinking is “get it done, and get it done quick”, and as always later “get it changed, and get it changed quick”.
How appropriate. I found this entry while waiting for a long training piece to compile. It’s about 60 screens long and one of the requirements is that it be self contained. The compile time is around 5 minutes on a 1.13ghz PIII.
This project is due tonight, but for the next one,I’m sure your tip will come in useful. Thanks.