It is true that Flash¹s default frame rate of 12 fps is overkill for most business applications and could be adjusted to help keep code bits in sync. However, this time between refresh operations is relative and doesn¹t include the time it takes to render a frame - and Flash is smart enough drop frames to keep things moving. So really... using frame rates and timers in your application probably isn¹t the best idea.
The problem is that people (developers) get impatient and tend to want things to happen on their time and forget that the framework is doing a pretty good job... and that they just need to be better friends with rendering cycles and the display list. Rick Winscot On 12/23/08 11:13 PM, "Amy" <amyblankens...@bellsouth.net> wrote: > > > > --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> , > "Manish Jethani" > <manish.jeth...@...> wrote: >> > >> > On Wed, Dec 24, 2008 at 2:23 AM, Amy <amyblankens...@...> wrote: >>> > > --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> >>> , "Tracy Spratt" <tspratt@> > wrote: >>>> > >> >>>> > >> A quick google indicates that, as Manish says, current thinking > is >>> > > to >>>> > >> use timer for this type of work. >>> > > >>> > > I'm not sure I agree with this, since a timer can't react before > the >>> > > next frame anyway (i.e. the most accurate a timer can be is the > frame >>> > > rate). >> > >> > Agreed. The benefit of a timer-based thing is that you can slow it > down further. > > To every other frame or every thidr frame or... ;-) > > Of course, you can change the frame rate to get a timer that's > accurate to the timing you want. > > -Amy >> > >> > -- >> > manishjethani.com >> > > > >
