Hi after24, >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?
>When the user start to scroll, the actual viewport is removed (using >removeElement) and replaced by the ViewportCache component. >When the scroll is complete, the ViewportCache is removed (using >removeElement) and replaced by the actual viewport. 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, 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. >I found out a way to detect this type of interaction for example the user >click the bitmap version of a ToggleButton on the ViewportCache, but I can not >reflect this interaction on the actual viewport i.e. the actual ToggleButton >should be toggled, when it’s added back to the display list. I would recommend that you listen the TouchInteractionEvent.TOUCH_INTERACTION_START event on Scroller. Usually the Scroller instance itself does not dispatch this event, the viewport's sub component (or sub sub sub component) dispatches this event when the scrolling has just started. So when TouchInteractionEvent.TOUCH_INTERACTION_START happened, you can draw the viewport to viewportCache, then set the viewport's visible to false, and set viewportCache's visible to true. You should also listen TouchInteractionEvent.TOUCH_INTERACTION_END event on Scroller, when it happens, set viewportCache's visible to false, and the viewport's visible to true. http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/UIComponent.html#event:touchInteractionStart http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/UIComponent.html#event:touchInteractionEnd >Do you think it's feasible? anyone has an idea? I think it's feasible, but this approach has the following drawbacks: 1. You will need to use the BitmapData.draw() to create a bitmap version of the viewport, the total number of pixels of a BitmapData cannot exceed 16,777,215 pixels, although it's large enough, it has its limit. 2. If a BitmapData's size is very big (on Retina Display big size content is very common), it will consume a lot system memory, which could potentially crash the application on mobile device, or decrease the overall performance. Well, I think it's still worth a shot, hope what I said could help you somehow : ) DarkStone 2014-10-24 At 2014-10-24 19:24:35, "after24" <vinc...@after24.net> wrote: >Hello, > >I have worked on a way to optimize the scroller component on mobile.. >It's very promising, especially for very complex views, but there is a major >drawback though. > >Here is how it works : > >The scroller component has a new boolean property called cacheViewport : > >When this property is set to true, a bitmap version of the viewport is >captured in a ViewportCache component which inherits from >SpriteVisualElement and implements IViewport. >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. > >When the user start to scroll, the actual viewport is removed (using >removeElement) and replaced by the ViewportCache component. >When the scroll is complete, the ViewportCache is removed (using >removeElement) and replaced by the actual viewport. >When the user interacts with the viewport content, the ViewportCache has a >system that redraws the regions that are likely to have changed during those >interactions. > >The weakness of this method is that the viewport must be added to the >display list after each scrolling operation : this process can be very long >(500-1000 ms) for very complex views. > >The idea to solve this problem would be to add the actual viewport back only >when the user interacts with its content. > >I found out a way to detect this type of interaction for example the user >clic the bitmap version of a ToggleButton on the ViewportCache, but I can >not reflect this interaction on the actual viewport i.e. the actual >ToggleButton should be toggled, when it’s added back to the display list. > >Do you think it's feasible ? anyone has an idea ? > > > >-- >View this message in context: >http://apache-flex-development.2333347.n4.nabble.com/Scroller-optimization-tp41774.html >Sent from the Apache Flex Development mailing list archive at Nabble.com.
