Skip navigation
Currently Being Moderated

Character Animation—managing data rates for "heavy" SWF files?

Apr 7, 2012 11:03 PM

Tags: #cs5 #flash #animation #character_animation #optimize #clunky #data_rate #heavy

I am currently taking a digital character animation course using Flash CS5. I am producing short cutout character animations completely inside of Flash (no imported bitmaps). My final SWF files are only 10 second looping animations with a file size around 300kb. And yet, my instructor is saying that they are too heavy or too clunky and that I need to watch my data rate for my final project. My final project is supposed to be upwards of 20 seconds long.


At one point, it was suggested that I export my Flash project as a PNG sequence—import into After Effects—export the AE sequence... to what? I wasn't told. But, I tried both SWF and MOV. The MOV ran okay, the colors were pretty washed out. But the SWF files were completely perplexing. My original 300kb file ran fine (on my computer). But the AE SWFs were a nightmare. I exported three to see what the difference was: the first was at the highest quality (10) and came out a whopping 39 MB. Quality 5 came out 9 MB. And Quality 0 came out at 4.9 MB. ???


None of them looked as good as the original 300kb file.


My question(s): I'm trying to figure out how to manage Flash so that I can produce—not just a 20 second project for this class, but—short animated stories. How are people using Flash on the web to do anything longer than 10 seconds IF those 300KB are too heavy and stumble on playback? Why is Flash Player choking on what I consider a relatively small file?


If someone is willing to take a look at the file and discuss this with me, I'd be happy to send a link. A crappy version of the MOV exists here:

  • Currently Being Moderated
    Apr 8, 2012 6:49 AM   in reply to bjgough

    You may find that there are many different ways to accomplish what you are attempting... so without going into detail, here's just a few basic things to consider.

    First, set the Flash stage to exactly match the final display target size.... don't create a 1000 x 500 stage if the final Web page display is only 500 x 250.

    All/most of the graphics should be vector rather than bitmaps (jpg, png, gif, tiff).

    If you do have to use any bitmaps, be sure to resize them outside of Flash to the exact dimensions needed on the stage..... don't bring a large image into the library and then scale down in Flash.... doing so just bloats the file size.

    Elements on the stage can be broken down into smaller sections and turned into symbols that can be used over and over. That way you won't need to create a whole new item if only one small part is moving/changing. Look at each element and movement sequence and determine what is the least number of moving parts you need to accomplish it..... reuse, repeat, recycle.

    I would stay away from ANY video format if file size is a concern.... you will not do any better than .swf.

    As for a 300kb file size... I wouldn't be too concerned if that was my file.... but the instructor has a very good point, learn from the very beginning to optimize the elements of a Flash doc and keep the file size small... choose the correct dimensions to start with... don't scale, keep Library elements to bare minimum... re-use, re-peat, re-cyle those elements.

    And I don't presume to question you instructors comments, rather I'll hopefully add a little to your knowledge and understanding of "data rate".... though I'm not sure that "data rate" would be the best terms to use.

    Data rate, or data "bitrate" is the amount of data that must continually flow into the display media (in this case the .swf) to display the animation uninterupped.

    A simple .swf will differ from a video, for example, in that all the data may need to be downloaded before the animation can start, while in a video, only a small part of the video .... the first hundred frames or so... needs to download, then as the video displays, the downloading will "progress" and finish downloading the file.

    How fast the file is downloaded is a function of the viewers Internet connection speed. This download speed is measured in kilo bits per sec.

    So how long would it take to download a 300kb file? Well that of course depends on the viewers connection speed.

    300kb(ytes) = 300 x 8 (bits/byte) = approx 2400bits

    On a 1Mb(it) connection it would take approx 2.5 sec.

    On a 6Mb(it) connection it would take approx .4 sec.

    Test you connection speed here:

    You can also approximate download time with the Flash bandwidth profiler. That and other Flash "Optimization Practices" are discussed here: b1fe1af6-7b23a.html#WSd60f23110762d6b883b18f10cb1fe1af6-7b1aa

    Best wishes,


    Mark as:
  • Currently Being Moderated
    Apr 8, 2012 12:44 PM   in reply to bjgough

    So, a SWF needs to download entirely before playing back? (it doesn't stream like a video does?)

    Actually this depends a little on the particular .swf. For example, if you have a .swf that makes good use of re-use, re-peat, and re-cycle, the .swf may need all the library content downloaded in order to display frame 1, after that, all action on the stage simply reuses some or all that library content... then all content needs to be downloaded before the .swf starts.

    Where as another .swf with a long timeline may be constantly displaying new stuff.... so then there can be time to download the content used in frame 250 for example.

    "stream" like a video is not quite the correct terminalogy... what you most likely mean is "progressive download" like a video. Although video files can be "streamed".... that's a different subject.

    Progressive downloading means that the video file downloads the data for the first hundred frames or so, then the display starts while the rest of the download progesses, until the entire file is downloaded.

    But yes, .swf files CAN be progressively downloaded.... for example:

    click the link and watch the download progress bar in your browser..... display starts and "progresses" as the .swf plays.

    This is a single .swf of 28MB. In this case it's an embedded video where the contents of frame 200 is not needed at all to display the first 199 frames... so it can be progressively downloaded. And in case you are wondering, the embedded video has a bitrate of 400kbps.

    So approx 6 sec of data from this .swf would equal the file size of your .swf... pretty tiny by comparision .... your .swf would play for 10 sec while mine only plays for 6.

    But yours may need all or nearly all that content loaded to display frame 1... so you may need to download the entire .swf before display starts.

    Now how about this... take and copy your entire timeline and paste it onto the end of the current timeline (save as test.fla). You may find little or no increase in file size because you are simply reusing content.

    So your 20 sec final version will not necessarily be twice the file size of your 10 sec version.

    • They are posted in a class discussion forum, where viewing requires downloading onto your local machine and then viewing in Flash Player.

    If this downloading is done over a LAN, or closed network, downloading should be very fast, most likely much faster than any Internet connection. 300kb should download in the blick of an eye.

    And once on your local machine, there is little or no reason for

    compromising its ability to play in the Flash Player.

    it will play just fine once on your local machine:

    too heavy or too clunky

    then really loses all meaning. I'm sure your instructor meant that in the sense of heavy or clunky in downloading the file.

    It sounds like you have already pretty well optimized your .swf... and like I said 300kb is not that large a file. But still, it's best to learn to mimimize/optimize from the beginning.

    Best wishes,


    Mark as:
  • Currently Being Moderated
    Apr 12, 2012 11:21 AM   in reply to bjgough

    Well it's still my opinion that a 300kb .swf file played from a local machine is anything but "heavy and clunky".

    That's a very small file and should play back smooth.

    I have noticed inconsistencies in Flash Player when playing back these class assignments

    If this is in a classroom of students who are just learning Flash, I'd say there is a better chance of problems with the Flash files that the students are creating than problems with the Flash player itself.... and I'm speaking as a former student myself!

    Now when you talk about sound in the Flash file, you are talking about something all together different!

    Sound can be sort of a tough challenge when learning Flash. Remember that there are basically two ways for Flash to handle sound, "Event" sounds which play from beginning to end regardless of what else is going on on the timeline... like a short "beep" or musical tone when a button is clicked or door opens..

    The second way Flash uses sound is "streaming", meaning Flash will play the sound and the animation going along with it may or may not keep up. This will vary depending on the Flash doc frames per sec, the size and complexity of the Flash file as well as the ability to download data into the Flash player fast enough to keep up.

    So all it takes is a few missed labeled sound clips ... event when it should be streaming... streaming when it should be really sound whacky. It's not the players fault, it's the student that mis-used the sound type that's the root cause.

    to name just a few links that discuss this.

    So yes you should be creating all content to the exact dimensions needed in Flash... Do NOT scale in Flash.

    But if you get a 300kb Flash file that is "heavy and clunky".... show me.

    I still say "heavy and clunky" relates to download speed. IF it plays slow or acts clunky on a local machine, the fault is not the fact that the file is 300kb, it's that the content was not created or managed properly... final size had nothing to do with it.

    Best wishes,


    Mark as:
  • Currently Being Moderated
    Apr 13, 2012 7:32 AM   in reply to bjgough

    Got 'em!

    Here's my two cents worth...

    The animation with sound seems to run fine. I don't notice any sync problems.

    The running animation on the other hand seems to be rather "heavy and clunky"....

    Here's me eating my words ..()[]()[]()[]()[]...

    OK so you can have a 300kb .swf that is heavy and cluncky!

    When I click and open the running animation, it opens at a small size ... 600 x 400 or something like that. And it actually runs just fine! Where it really starts to get "heavy and clunky" is when I start to enlarge it. As I drag to enlarge from original size to full screen, the animation starts to slow down, and by full screen is at less than half speed.

    Since nothing is being added to the animation as it goes along, the only reason it would be slowing down is that the CPU and graphics display on my machine is struggling to keep up.

    While not a new machine, it is a dual core 4GB ram and the monitor is 1680 x 1050.... yet it struggles at full screen.

    To test my theory, I used Task Manager to monitor the CPU.

    The run animation at original size is running the CPU ar almost 50% (pretty darn CPU intensive) and then goes up from there as the display size increases. The result is that the animation appears sluggish, heavy, and clunky.

    But it really has nothing to with the file size, rather it's because in the animation, every single pixel on the monitor is constantly changing.... having to be redrawn (moving background, animated characters, cloud bursts, etc). That is a very intense process and is overwhelming the capacity of my machine.

    Now you might test on a new i7 64GB RAM SuperDuper VidSlammer card and get it to play just fine.... But I think the lesson is that you need to be aware of the graphic demands put on the machines CPU/graphics unit.

    The fewer pixels that are changing at any one time, the less work the machine will have to do.... making for snappy animations.

    Do your own CPU tests as you run the animation to see your own results.

    Best wishes,


    Mark as:
  • Currently Being Moderated
    Apr 15, 2012 11:32 AM   in reply to bjgough

    The original stage size is 540x400, so, I wouldn't expect it to perform better scaled up... (although, these are vectors, right!?)

    But remember, it's precisly because these are vector images, the color at any one location is not set from one moment to the next. A mathmatical computation involving both the scaling as well as the new color (as the animation scrolls across the screen) has to be handled by the CPU. As you scale a vector, new mathmatically calculations are constantly being done.

    Vector graphics is the use of geometrical primitives such as points, lines, curves, and shapes or polygon(s), which are all based on mathematical expressions, to represent images in computer graphics.


    This is not the case with a a video or jpg image. While the color of a particular pixel may change as the animation scrolls by... there is no math computation involved.

    And, since the resolution of a video is set at rendering time, there is no real mathmatical scaling involved, rather if one pixel is red and you quadruple the display size from 320 x 240 to 640 x 480.... now there are four red pixels. The CPU and/or graphics card are able to compute the color of those 4 pixels much easier scaling a bitmap than scaling a vector. The video simply gets blurry as the display dimension increases (take the color of the neighboring pixel and use that)... degrading the quality, unlike the vector image which the computer attempts to keep at exactly the same quality, pixel for pixel.

    Of course this is a very simplistic explanation. Going into detail of video codecs and bitrate would best be left for another post.

    While vectors are great for scaling, it's the continual movement of so many elements of your Flash project that is causing the problem. It's not the fact that the images are vectors and it not because the file is 300kb... it's the contstant movement of every pixel on the screen.

    To verify my theory, test your running man against a stationary background... turn off/get rid of other constantly changing elements, like the cloud bursts. I assume those are created in actionscript using a random number, random size, and random location. These mathmatical calculations also absorbs CPU power. Test without the cloud bursts.

    Do some experimenting and find the biggest problem element... then maybe change or eliminate that.

    More (animation) is not necessarily better animation. Take a look a movies and video on the Web. Most clips have a stationary background... short clips can be pieced together to change the viewers perspective. Especially for video intended for the Web, panning or zooming the camera is greatly discouraged because it takes a much greater bitrate (datarate) during that portion of the video.

    Anyway, best of luck on your project!


    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points