7 Replies Latest reply on Nov 28, 2010 6:49 AM by Craig Grummitt

    Scroller slow in Google Chrome

    Craig Grummitt Level 3

      I have a horizontal Flex SDK scroller, with content that is very wide. This doesn't present a problem in firefox or safari, but in Google Chrome(on the mac, haven't tested on PC) the movement is very jerky. I can't imagine how to resolve this in the code, if the result is inconsistent between browsers all I can think of is perhaps Google Chrome has a known problem with memory management or something similar... But then other people should be seeing this problem, and I can't see any other posts regarding it. Has anyone encountered this problem?



        • 1. Re: Scroller slow in Google Chrome
          Shongrunden Adobe Employee

          I haven't run into this, is there any chance you could provide some sample code that demonstrates the issue?

          • 2. Re: Scroller slow in Google Chrome
            Craig Grummitt Level 3

            Ok I stripped down my code to arrive at just the scroller, to show you.

            My initial Scroller contained a custom ButtonBar component with a series of custom buttons.

            I tried stripping it right down to just putting an image in the scroller, and that wasn't showing the problem.

            Then I tried stripping it down to just showing a series of images, and that wasn't showing the problem.

            So the problem may be in the combination of the scroller, with the custom buttonBar/custom button i've created.


            So before you look at it let me explain what you'll see.

            I've created my own ButtonBar component. I did this to resolve issues inherent in the Flex ButtonBar component (see bug report here.)

            I created a CustomButton to permit the inclusion of a selectable button with a checkbox inside it.


            For me scrolling is much more jerky in Chrome than Firefox/Safari. I'm on a Mac.




            (View Source is enabled)




            • 3. Re: Scroller slow in Google Chrome
              Shongrunden Adobe Employee

              Thanks for the example.  It looks slightly slower for me in Chrome, but not by much.


              Is there a reason you aren't using a List/DataGroup with virtual layout?  You'll get much better startup time and in this case it might even help with the scrolling performance problems you are seeing.

              • 4. Re: Scroller slow in Google Chrome
                Craig Grummitt Level 3

                I'm thinking if you're not seeing a great difference between firefox and chrome, it may be to do with your computer being so fast, the difference is negligible. So I've updated the online version which allows you to increase the number of buttons(previously it was 1000) that are generated, and maybe you'll be able to see the difference more clearly. For me and my client, as it is, interaction with the scroller in firefox is good yet the jerkiness of the interaction in chrome means it is difficult to use.


                You can see this new version in the same place:



                I have followed your advice, and reworked the code into a DataGroup. Unfortunately I'm not seeing your proposed better startup time, nor does it seem to affect the jerkiness in chrome. You can see this test here:



                • 5. Re: Scroller slow in Google Chrome
                  Shongrunden Adobe Employee

                  Every item in the DataGroup's dataProvider will be instantiated.  It looks like you are still creating all of your Buttons and putting them in your dataProvider.  This won't give you any performance benefit, in fact it might make it worse since you are then wrapping each of those components in a DefaultComplexItemRenderer.


                  What you should do is build an ItemRenderer using your Button.  That way your dataProvider will only be the data that those Buttons need rather than the Buttons themselves.  Then if you have useVirtualLayout=true on the DataGroup's layout only a handful of Buttons will be created (enough to render only what is currently in view) rather than thousands.
                  1 person found this helpful
                  • 6. Re: Scroller slow in Google Chrome
                    Shongrunden Adobe Employee

                    Here's a simple example:


                    <?xml version="1.0" encoding="utf-8"?>
                    <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
                                import mx.collections.ArrayList;
                                public function getDataProvider(n:int):ArrayList {
                                    var arr:Array = new Array(n);
                                    for (var i:int = 0; i < n; i++)
                                        arr[i] = i;
                                    return new ArrayList(arr);
                        <s:Scroller width="500">
                            <s:DataGroup dataProvider="{getDataProvider(10000)}">
                                    <s:HorizontalLayout useVirtualLayout="true" />
                                            <s:Button label="{data}" />


                    Notice that even with 10,000 items in the dataProvider the startup time is minimal since there are only 6 ItemRenderers in view at one time so only a few more than that need to be created.

                    • 7. Re: Scroller slow in Google Chrome
                      Craig Grummitt Level 3

                      Virtual Layout, of course! I was of aware of the feature but was neglecting to make the most it. Thankyou Shongrunden, for pointing that out, there is now no problem in Chrome, and the scroller is better in general. As the docs says 'If the container has many children, you might notice performance degradation        as you add more children to the container.'...

                      Thanks again!