1 Reply Latest reply on Mar 22, 2010 1:27 PM by Flex harUI

    Flex rendering: performance and escalation problem

    SilvaDev

      I'm building an dynamic application that load a different types of forms, this forms are created by
      user, setting what visual component’s that will be contain.

       

      Application screenshot:

       

      App_Visual_Hierarchy.jpg

      After implemented all common performance best practice techniques, could turn the application
      more stable, but running tests, rendering a form containing one only component type (custom
      component class extends uicomponent and have three child's: label, textinput and button) inside a
      container canvas with border, when run a form that have until 100 custom component, the
      application still good, but with more than 100, the application rendering time explode and after so
      much time trying to identify the cause of that, i can't. For better understanding, see below the
      graphic with the performance tests results in comparison with the actual client application, done in
      html/js:

       

      ScreenShot002.jpg

       

      Some applied techniques:


      • Fixed width and height for doesn't invoke measure() lifecycle method;
      • Minimum usage of setStyle() invocation for each component;
      • Minimum container usage;
      • Deferred instantiation “queued” for tabnavigator;
      • RSL (Run time Shared Libraries);

       

      The main problem is find any way to show the form more quickly, with a minimum difference of
      current client (html/js), and scalable, that not explode when have to show a form that have more
      than 100 visual components.


      Please, any idea or suggestion will welcome to help to fix this problem.

       

      Thanks,

       

      Silva Developer

        • 1. Re: Flex rendering: performance and escalation problem
          Flex harUI Adobe Employee

          That's one of the reasons the DG virtualizes what it shows.  It only creates

          renderers that are visible.  If you get to hundreds of display objects

          you'll start to feel it.

           

          So, one choice is to virtualize

          Another is to lighter weight custom UIComponents.  Your should be a single

          UIComponent with three children, a dynamic textField for the label, a input

          textField for the input, and if you  are really desparate, a SimpleButton

          for the Button.  There's be a bunch of stuff to glue together but it will

          probably be worth it.