Hi after24,
>At first I used the visible property to hide the actual viewport during scroll >operations but this method has a significant impact on performance. I'm not >sure about the cause but the fact that the viewport remains on the display >list even if it's not visible hurts performance. This issue is probably caused by Scroller and the viewport's layout. When scrolling with finger, the Scroller will update viewport's horizontal and vertical scroll positions (actual work is done by viewport.layout), and might involk some other layout API of the viewport. The instance to the viewport.layout property is responsible for updating the viewport's scrollRect, and maintaining the layout of the viewport's direct children, depending on the structure of the viewport's children, this might consume a lot CPU resources. In order to solve this, you can try to set the viewport.layout to null when scrolling, and set viewport.visible to false, this will disable the layout functionality of the viewport, and save a lot CPU resources. But it might not work if you just embed your ViewportCache directly to the Scroller, you may need to reconsider the CacheableGroup approach I suggest you in the last reply. If you go with the approach of CacheableGroup, the benefit is you don't have to change the source code of the Scroller component at all, it can remain untouched. For developers that want to improve the scrolling performance on mobile devices, they can choose to use CacheableGroup for the Scroller.viewport, for developers that don't do mobiles, they may don't need it at all. Hope it helps, good luck~ DarkStone 2014-10-26 At 2014-10-26 16:11:01, "after24" <vinc...@after24.net> wrote: >Hi DarkStone, > >Thank you for your response. > >* >/Instead of using the scrollRect property of the viewport, the ViewportCache >performs the scrolling of the bitmap version of the viewport using the >blitting technique which is way much faster. >What do you mean by "the blitting technique"? Could you explain it in >detail?/* > >This technique involves a bitmap canvas on which blocks of bits are copied ( >wikipedia <http://en.wikipedia.org/wiki/Bit_blit> ). Here, the canvas is a >Bitmap whose dimensions are equal to the viewport ones. The actual viewport >is rasterized in a BitmapData using the draw method. The viewport is >rendered using the copyPixel method of the bitmap canvas (copyPixels is very >fast). > > >* >/the total number of pixels of a BitmapData cannot exceed 16,777,215 pixels, >although it's large enough, it has its limit./* > >My ViewportCache has a ViewportRasterizer class which performs the >rasterization work : the rasterized version of the viewport is stored in a >vector of BitmapData objects with a maximum size of 2880 x 2880. This way, >even very larges viewports can be rasterized in multiple tiles (a Vector of >Rectangles is used to store the position and size of each tile). I made some >tests on my nexus 4 with a 480 x 28 000 pixels viewport and it works at a >steady 60 fps when cacheViewport = true > > >* >/I would rather create a subclass of Group named "CachableGroup", define two >properties for CacheableGroup: viewport:IViewport (default property) and >viewportCache:IViewportCache, then set Scroller.viewport to CacheableGroup. >The viewport property is like the actual viewport of yours…/* > >I choose to integrate the viewportCache inside the scroller component so >that the user can leverage the optimization without having to change his >code (just set a property to true). Furthermore, it's easier to know when >the throw effect is complete when the optimization is implemented inside the >scroller. > >* >/and I also would rather set the viewport or the viewportCache's visible to >false than using removeElement() when you don't need one of them. Cuz if you >need to show one of them (the viewport or the viewportCache) back again, the >addElement() method will have to take some time to render it, it's much >slower than setting its visible from false to true./* > >Yes, this is the problem. At first I used the visible property to hide the >actual viewport during scroll operations but this method has a significant >impact on performance. I'm not sure about the cause but the fact that the >viewport remains on the display list even if it's not visible hurts >performance. That's why I choosed to remove the viewport from the scroller >skin during scrolling, in this case, performance is optimal but then, the >time needed to add it back when the scrolling is complete can be very long. > >Does the runtime renders every display objects added to the display list >even if their visible property is set to false ? is the decrease in >performance between the two approaches is due to the the scroller component >? > >I will make some tests with scout to see if I can identify the difference. > >If this problem can be solved, this optimization will have a huge impact on >scrolling performance (as I said before, I was able to scroll enormous views >at 60 FPS using this technique). > > >Vincent. > > > >-- >View this message in context: >http://apache-flex-development.2333347.n4.nabble.com/Scroller-optimization-tp41774p41814.html >Sent from the Apache Flex Development mailing list archive at Nabble.com.
