1 Reply Latest reply on Jan 13, 2009 11:37 AM by Newsgroup_User

    FlexEvent.RENDER vs Timer

    paulv410
      There are times when my application is going to have to do a lot of processing to apply a large number of changes. These changes include adding and removing things from the display list among other calculations, etc. The processing time could be significant so I need to break the changes into smaller work items which can be done on different frames.

      I am wondering what is the best way to "queue" the next chunk of work to be processed. In UIComponent, the callLater() method listens for the FlexEvent.RENDER and calls the appropriate method. I have also seen examples where people use a timer with a short duration to schedule the next work item.

      My processing is not being done by a UIComponent so I would have to set up my own listener for the render event if I used that method. This seems like a cleaner solution than the Timer method, but I don't know if there are any limitations with making changes on the Render event.

      Does anyone have any best practice recommendations for performing large tasks as small work items?
        • 1. Re: FlexEvent.RENDER vs Timer
          Level 7

          "paulv410" <webforumsuser@macromedia.com> wrote in message
          news:gkinu8$s62$1@forums.macromedia.com...
          > There are times when my application is going to have to do a lot of
          > processing
          > to apply a large number of changes. These changes include adding and
          > removing
          > things from the display list among other calculations, etc. The
          > processing
          > time could be significant so I need to break the changes into smaller work
          > items which can be done on different frames.
          >
          > I am wondering what is the best way to "queue" the next chunk of work to
          > be
          > processed. In UIComponent, the callLater() method listens for the
          > FlexEvent.RENDER and calls the appropriate method. I have also seen
          > examples
          > where people use a timer with a short duration to schedule the next work
          > item.
          >
          > My processing is not being done by a UIComponent so I would have to set up
          > my
          > own listener for the render event if I used that method. This seems like
          > a
          > cleaner solution than the Timer method, but I don't know if there are any
          > limitations with making changes on the Render event.
          >
          > Does anyone have any best practice recommendations for performing large
          > tasks
          > as small work items?

          The timer is tied to the frame rate..i.e. the timer cannot respond to any
          increment of time smaller than 1 sec/frame rate. That's not an answer, but
          should help you evaluate your options.

          HTH;

          Amy