4 Replies Latest reply on Oct 12, 2011 8:32 AM by ozDiGennaro

    Build monster UI in background (threaded)


      Hello everyone


      I have a visual component with many children which all will be added using actionsript. Some of the children are other components. Now, my AIR application (but I assume the same holds also for Flex) will hang for some seconds before showing the visual component. So, assume there is the function buildUI() which will start building the UI. Like


      function buildUI():void
        var c:MyComponent = new MyComponent();
        c.addElement(new MyComponent2());
        c.addElement(new MyComponent6000());


      Now I have put a indeterminate ProgressBar on my stage and then called the buildUI() function upon a button click. After a while, the progressBar would stop moving (freeze) and then after another while, the new MyComponent would be shown. Is there a way to avoid this? My idea: The MyComponent should be created in a thred which would not block the main movie. But, Flex obviously does not know of Threads.


      Thanks for your reply.

        • 1. Re: Build monster UI in background (threaded)
          Amy Blankenship Level 4

          Set the progress bar not to be indeterminant, then generate progress events from your buildUI as it builds.  Or set things up so the entire UI doesn't have to build before you can show something.

          • 2. Re: Build monster UI in background (threaded)

            I'd agree with Amy, generate a some kind of progress events as you traverse through the UI build, events and their handling are async. Im not sure this means threads, but it sure acts that way!

            • 3. Re: Build monster UI in background (threaded)
              UbuntuPenguin Level 4

              Messing around with the visual innards of Flex is my weak point ( one amongst many ). But




              then called the buildUI() function upon a button click.


              This seems a little sketchy.  The UI components in Flex have deferred instantian meaning that they are created when they are needed.  This allows for faster startup time and avoidance and better performance of UI components. I assume that when you have the buildUI() function, you are in a way bypassing some of the benefits provided by the framework in terms of component lifecycle and deferred creation of objects.  Your buildUI thread is going to block,

              I assume, meaning that not too much else is going to happen until it is done which is probably why your UI  appears to freeze.


              >...My idea: The MyComponent should be created in a thred which would not block the main movie. But, Flex obviously does not know of Threads.


              The flashplayer as of now is single threaded, they have a multi-threaded one in the next release I believe but I am not sure of the specifics.  I don't know of how much of a help it would be because you have to understand the flashplayer component lifecycyle AND concurrency. 

              • 4. Re: Build monster UI in background (threaded)
                ozDiGennaro Level 1

                I understand the problem, since I've faced it also.  Remember, threads don't get you more compute power.  In fact, if there are several compute-bound threads, it will actually finish slower than a single thread, because of thread-switching overhead.


                No threads yet in Flex, but if you are using HTTP requests, the I/O event hander runs in a lightweight thread context.  Overlapping I/O and graphic activities can result in better performance.


                I like using a sequence of adding children, so that the user sees that things are happening.  Much more satisfying than a progress bar.


                If you are using Flex Builder 4.5 Pro - you can analyze for performance bottlenecks.  You can even get a trial version for a month - maybe that would be enough time to speed things up.  I was able to get a factor of TEN speedup by analyzing the bottlenecks and optimizing only them.  I use many many custom components which extend BorderContainer, and I get good performance.  But when I had hundreds of these custom components created at start time - it was slow.


                Do the performance analysis, and then fix the slow spots.  You'll be surprised where you are spending your compute time.


                1 person found this helpful