Hi I've been loosely following this but have you tried setting include in layout to false when setting visible to false? It may be that somewhere an invalidation is still getting called even though visible is false on the viewport.
Also, when are you caching the viewport? I would cache it as soon as you start to receive scroll instructions. Check out BitmapUtils class for a very fast screen / display object grab. In my 2011 laptop it took 17ms to capture the screen. On Monday, October 27, 2014, DarkStone <darkst...@163.com> wrote: > Hi after24, > > >/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./* > > > >I'm not sure about that because when the actual viewport is replaced by > it's > >cached version, the _viewport property of the scroller is actualized to > >point on the viewportCache. So the horizontal and vertical scroll > positions > >shouldn't affect the actual viewport layout during scroll operations. > > I was not talking about the scenario of "the actual viewport is replaced > by it's cached version". > > I was talking about the the scenario of setting the actual viewport's > visible to false, rather than removing it from the display list. > You were saying you had performance issue with the visible approach, so I > told you what might cause that issue in the last email. > > > DarkStone > 2014-10-28 > > > At 2014-10-28 06:18:35, "after24" <vinc...@after24.net <javascript:;>> > wrote: > >Hi darkstone, > >* > >/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./* > > > >I'm not sure about that because when the actual viewport is replaced by > it's > >cached version, the _viewport property of the scroller is actualized to > >point on the viewportCache. So the horizontal and vertical scroll > positions > >shouldn't affect the actual viewport layout during scroll operations. > > > >This stackoverflow > >< > http://stackoverflow.com/questions/10037262/building-small-gui-engine-visible-vs-addchild-removechild > > > >post could be an explanation of the difference in performance. > > > >Vincent. > > > > > > > >-- > >View this message in context: > http://apache-flex-development.2333347.n4.nabble.com/Scroller-optimization-tp41774p41883.html > >Sent from the Apache Flex Development mailing list archive at Nabble.com. >
