Re: FLASH: Framerate vs. Speed

[Troy M. Gilbert]

>> Thankyou for the answers about frame rate, although I think there is still

>> something missing. If you set the "speed limit" to 12fps and a movie runs at

>> 9fps, then setting it at 9fps shoult not make it run at 6fps.


Well, I put my programming mind to it and I came across would could be a

possibility. Please note: I have no real factual information that leads me

to think Flash does this except that it's a technique often used for

achieving framerate-based animation.


(In case you don't want to read the whole description, here's the synopsis:

Flash most likely determines its inter-frame pause statically; it should be

determined dynamically because of the variable rendering time of vectors.)


Now, take a deep breath and dive in:


To keep a steady framerate, the Flash player must render its graphics at

regular intervals. To accomplish this, a program normally renders the

graphics to the screen then pauses for a set amount of time, normally

something close to 1000/(desired framerate) milliseconds. So, for example,

if you are running an animation at 10 fps, the program will render your

first frame, pause for 1000/10 = 100 msecs, then render the next frame,

pause for 100 msecs, render, pause, render, etc... This normally works

great when rendering bitmaps (e.g. video) where all the frames take roughly

equivalent amounts of time to render.


The problem in Flash occurs because vectors can take variable amounts of

time to render. Lines are quicker than circles, solid colors quicker than

gradients, 100% alpha quicker than 50% alpha, etc... Here's what I think

happens with Flash (this is an example and frame rendering times are

grossly exaggerated):


frame 1 takes 10 msecs to render, frame 2 takes 15 msecs, frame 3 takes 25

msecs, frame 4 takes 20 msecs (the different rendering times could vary

quite a bit with overlapping objects, anti-aliasing, objects going on and

off the screen, etc.)


You set your animation to run at 20 fps, so Flash calculates the delay

between frames to be 1000/20 = 50 msecs. So, Flash renders frame 1 (10

msecs) and pauses (50 msecs), renders frame 2 (15 msecs) and pauses (50

msecs) and so forth... the total time to render four frames: 10 + 50 + 15 +

50 + 25 + 50 + 20 + 50 = 270 msecs to render four frames. Now, if you work

backwards to find out what frame rate that is: (total time)/(# frames) =

270/4 = 67.5 msecs per frame (on average), or 14.8 fps.


Okay, that all makes sense, the computer can't keep up. So you drop it down

to 10 fps, should be able to keep up, right? Well, Flash calculates a frame

delay of 1000 / 10 = 100 msecs. Doing the same math above we get: 10 + 100

+ 15 + 100 + 25 + 100 + 20 + 100 = 470 msecs / 4 frames = 117.5 msecs per

frame, or 8.5 fps.


So, the problem lies in the fact that Flash calculates the pause between

frames (inter-frame delay) statically based on the framerate.


Hmm... is it possible for an vector animator to keep an accurate framerate?

Yes, actually it is. I've programmed a dynamic inter-frame pause before.

Basically, the frame rate is recalculated each frame, and if the frame rate

it too high the inter-frame pause is increased by a certain percentage

(based on how far off it is); if the frame rate is too low then the

inter-frame pause is decreased until it hits a certain limit (if it becomes

too low, usually less than 10-20 msecs, the responsiveness of the computer

starts to be hurt).


Well, that was terribly long winded. But I hope that explained the whole

problem to everyone. If anyone still has questions don't hesitate to e-mail

me off list.


Troy.





------------------------------------------------------------------------

To UNSUBSCRIBE send: unsubscribe flasher in the body of an

email to

list-managershocker [dot] com

.  Problems to:

ownershocker [dot] com

N.B. Email address must be the same as the one you used to subscribe.

For info on digest mode send: info flasher to

list-managershocker [dot] com