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.
