Perhaps should have stated: "increase the .swf movie file size" (not the Flash file).
1 person found this helpful
original post is a response to:
neither is accurate. the flash player does the best it can to maintain the designated frame rate and, if the host computer is capable, it on average, maintains the designated fps.
here's an excerpt from a book (Flash Game Development: In a Social, Mobile and 3D World) i wrote:
Everything done by the Flash player uses CPU/GPU. That means everything displayed in your game and every bit of code that executes in your game requires processing by the CPU/GPU. In addition, if your swf's frame rate is greater than zero, even when there is nothing on-stage and no code executing, your game still uses CPU/GPU.
That is, if you open Flash Pro, save your fla and publish your swf, that game still uses the CPU/GPU when it runs. Even that empty stage swf with no code is repeatedly using the CPU/GPU.
For example, if your game's frame rate is 24, then 24 times per second (if the host computer/device can cope with that frame rate), the Flash Player does the following
- It checks for any events completed from the previous 1/24 second.
- Then it executes the listener function code, if there is any, for those events.
- Then if you have code on a frame that was just entered, that code will execute.
- Then it dispatches the Event.ENTER_FRAME event to all your listeners for that event.
- Then the display is rendered.
And, that is not all the Flash Player has to do. If you create an Object (i.e., anything) at any time, the Flash Player has to allocate memory for that object and it has to store that object reference and its value, if any was assigned when it was created. If there is no currently available memory Flash allocates more memory.
But, that's not all the Flash Player has to do. Before it allocates new memory, it checks for objects that can be removed from memory. If it finds any, it marks them for removal and, on a subsequent clock cycle, it clears that part of memory.
And the best (or worst) is yet to come. The marking of objects for removal is itself a dizzying multi-step process that involves checking each and every object that exists and then counting all the references to each and every existing object. All objects with zero references are marked for removing (sweeping in Flash parlance) and (eventually) cleared from memory.
Other than steps 3 (game code) and 5 (the graphics displayed), most of us do not consider the other steps that impact our game's performance. However, the time required to complete all five steps determine if your game runs smoothly or not. If the time required to complete all five steps is greater than 1/fps second, a frame will remain on-stage longer than 1/fps second. Put a few of those frames together back-to-back and your game appears to stutter.
There are two main points that I want to convey in this section:
- There is a lot going on in even the most basic Flash game and all of it uses CPU/GPU.
- Memory management has an impact, not just on memory, but also on CPU/GPU.
After seeing what the Flash player does many times per second, it is amazing that, for many game players, there are no noticeable performance problems with most Flash games. However, an increasing number of computer users, using relatively weak computing devices like mobiles, are having problems with Flash games (and everything else Flash).
1 person found this helpful
the published file(s) is (are) what matters. that's what the users will see.
but it doesn't even matter much what you're seeing on the computer you use to create published files. it matters what your users will see when they use your published files on their computer.
also, you should be using adobe scout to profile your files to get more info about your published files.
(p.s when using the adobe forums, please mark helpful/correct responses, if there are any.)