What you did seems very interesting, did you think about publishing your code and/or a demo, I guess it would help if you want some helps.
Frédéric THOMAS > Date: Sun, 26 Oct 2014 01:11:01 -0700 > From: vinc...@after24.net > To: dev@flex.apache.org > Subject: Re: Re:Scroller optimization > > 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.
