7 Replies Latest reply on Mar 21, 2009 8:06 AM by Newsgroup_User

    Slow AdvancedDataGrid rendering

    dalejoel Level 1
      Hello -

      I have a project that uses an AdvancedDataGrid with over 60 dynamically generated columns, grouped dynamically (there are three sub groupings above each actual colum), and fed with Hierarchical data. So each row of my ADG will expand one level to reveal another set of rows: Usually 5 at a time.

      This means, currently I'm drawing about 300 cells with colored backgrounds.

      Initially I used a Box for my custom item renderer to draw the colored backgrounds but found that the grid timed out when rendered. By switching to extend the AdvancedDataGridItemRenderer I picked up a SIGNIFICANT performance improvement. I set my background color in the set data( ) method of the item renderer. For the grouping column that expands, I use something derived from AdvancedDataGridGroupItemRenderer, coupled with setting the groupLabelFunction function.

      I overrode the AdvancedDataGridColumn to provide a custom dataTip function. Beyond that, I let default behavior happen.

      So what I'm noticing is that when I expand or contract the tree it takes a second or two of waiting before it draws. The set data( ) gets called on just about everything in the grid each time. Is this timing expected for my number of grouped columns and cells? I get the impression that others have larger tables with no lag. So maybe I'm missing something.

      I've been reading all sorts of thing to improve the performance. Eventually this table will be much much larger. By the time the application is fully mature, I will be responsible for displaying up to 20,000 colored cells. So I worry about having this not be usable as more data hits it.

      Initially I was setting the color in the validateNow function of the renderer. Moving it to setData and not overriding validateNow helped. What else do people suggest?

      So - to summarize:
      1) Should I be seeing a lag at all with 300 data points and 60 grouped columns?
      2) What are other things to look for to make this faster rendering?

      Thank you all,
      Joel

        • 1. Re: Slow AdvancedDataGrid rendering
          Level 7

          "dalejoel" <webforumsuser@macromedia.com> wrote in message
          news:gfvrjv$s2j$1@forums.macromedia.com...
          > Hello -
          >
          > I have a project that uses an AdvancedDataGrid with over 60 dynamically
          > generated columns, grouped dynamically (there are three sub groupings
          > above
          > each actual colum), and fed with Hierarchical data. So each row of my ADG
          > will
          > expand one level to reveal another set of rows: Usually 5 at a time.
          >
          > This means, currently I'm drawing about 300 cells with colored
          > backgrounds.
          >
          > Initially I used a Box for my custom item renderer to draw the colored
          > backgrounds but found that the grid timed out when rendered. By switching
          > to
          > extend the AdvancedDataGridItemRenderer I picked up a SIGNIFICANT
          > performance
          > improvement. I set my background color in the set data( ) method of the
          > item
          > renderer. For the grouping column that expands, I use something derived
          > from
          > AdvancedDataGridGroupItemRenderer, coupled with setting the
          > groupLabelFunction
          > function.
          >
          > I overrode the AdvancedDataGridColumn to provide a custom dataTip
          > function.
          > Beyond that, I let default behavior happen.
          >
          > So what I'm noticing is that when I expand or contract the tree it takes a
          > second or two of waiting before it draws. The set data( ) gets called on
          > just
          > about everything in the grid each time. Is this timing expected for my
          > number
          > of grouped columns and cells? I get the impression that others have larger
          > tables with no lag. So maybe I'm missing something.
          >
          > I've been reading all sorts of thing to improve the performance.
          > Eventually
          > this table will be much much larger. By the time the application is fully
          > mature, I will be responsible for displaying up to 20,000 colored cells.
          > So I
          > worry about having this not be usable as more data hits it.
          >
          > Initially I was setting the color in the validateNow function of the
          > renderer. Moving it to setData and not overriding validateNow helped. What
          > else
          > do people suggest?
          >
          > So - to summarize:
          > 1) Should I be seeing a lag at all with 300 data points and 60 grouped
          > columns?
          > 2) What are other things to look for to make this faster rendering?

          I'd either go with a style function or move it to commitProperties and set a
          flag in set data and call invalidateProperties(). There's a lightweight
          itemRenderer in my extended datagrid with style function you might want to
          look at. It doesn't include icon functionality, but you can look at it for
          the types of things you might want to do.

          http://flexdiary.blogspot.com/2008/09/extended-datagrid-with-stylefunction.html

          HTH;

          Amy


          • 2. Re: Slow AdvancedDataGrid rendering
            dalejoel Level 1
            Thank you Amy for the quick response, I will take a look.
            • 3. Re: Slow AdvancedDataGrid rendering
              dalejoel Level 1
              Hi Amy,
              So - I put in a style function for my ADG column. I put trace statements in the style function, the validateNow( ) of my renderer, and the set data( ) of my renderer. What I found was for an ADG with 60 columns under various groupings, the validate now function was getting called 8000 times on initial rendering. This is without calling super.validateNow( ). If I call that, it becomes 15,000.

              The style function gets called 7560 times.

              set data gets called 180 times.

              So it seems that actually changing the background color is not the problem as much as how many calls to the style function and validateNow happens.

              What is the advantage of the style function over doing the work in set data? Even in your example, to draw a background color you still needed an custom renderer to pull the style out to draw. So why not just do it in set data, especially with how much less that function is called?

              And why the heck is validateNow getting called so darn much? It really bogs everything down.

              -Joel

              • 4. Re: Slow AdvancedDataGrid rendering
                Level 7

                "dalejoel" <webforumsuser@macromedia.com> wrote in message
                news:ghmndu$d95$1@forums.macromedia.com...
                > Hi Amy,
                > So - I put in a style function for my ADG column. I put trace statements
                > in
                > the style function, the validateNow( ) of my renderer, and the set data( )
                > of
                > my renderer. What I found was for an ADG with 60 columns under various
                > groupings, the validate now function was getting called 8000 times on
                > initial
                > rendering. This is without calling super.validateNow( ). If I call that,
                > it
                > becomes 15,000.
                >
                > The style function gets called 7560 times.
                >
                > set data gets called 180 times.
                >
                > So it seems that actually changing the background color is not the problem
                > as
                > much as how many calls to the style function and validateNow happens.
                >
                > What is the advantage of the style function over doing the work in set
                > data?

                Set data sometimes occurs before createChildren, so depending on how you're
                handling the styling and what you're styling. But to me the biggest
                advantage is that you can create a generic itemRenderer that can be used in
                a variety of circumstances that doesn't have to have logic that connects
                styling to data. IMO, those are two separate tasks and should be treated as
                such where possible,

                > Even in your example, to draw a background color you still needed an
                > custom
                > renderer to pull the style out to draw.

                But once you have that renderer, you can use it anywhere to represent any
                data--the data and the styling are decoupled.

                > So why not just do it in set data,
                > especially with how much less that function is called?

                Set data doesn't know everything it needs to know to handle this, such as
                the size of the area it needs to draw.

                > And why the heck is validateNow getting called so darn much? It really
                > bogs
                > everything down.

                I'm not sure. Maybe the code was written close to deadline, and it was a
                way to get it just to work in the time available.


                • 5. Re: Slow AdvancedDataGrid rendering
                  ntsiii Level 3
                  set data() gets called very often, so don't do any work in there. You should only store your data locally and call invalidateProperties().

                  Then do the work in commitProperties, or updateDisplayList, or maybe createChildren, which are optimized.

                  Tracy
                  • 6. Re: Slow AdvancedDataGrid rendering
                    dalejoel Level 1
                    set Data could not possibly be called more often than commitProperties or updateDisplayList would be because everytime set Data is called, theoretically the data is changing so it's time to update anyway. It seems to me that doing work in set Data is the LEAST expensive way of changing things because updateDisplayList is going to get called all sorts of times regardless of changing data or not.
                    • 7. Re: Slow AdvancedDataGrid rendering
                      Level 7

                      "dalejoel" <webforumsuser@macromedia.com> wrote in message
                      news:gpsc4b$5ft$1@forums.macromedia.com...
                      > set Data could not possibly be called more often than commitProperties or
                      > updateDisplayList would be because everytime set Data is called,
                      > theoretically
                      > the data is changing so it's time to update anyway. It seems to me that
                      > doing
                      > work in set Data is the LEAST expensive way of changing things because
                      > updateDisplayList is going to get called all sorts of times regardless of
                      > changing data or not.

                      The least expensive way to do it is to set a flag in set data and then if
                      things need to change, then you do the work in commitProperties or
                      updateDisplayList. It's not terribly expensive to check a flag, but it can
                      be very expensive trying to set a property on an object in set data if that
                      object doesn't exist yet.