Hello Darkstone, Thanks for those tests. It would be very interesting that other users share the results they get on other devices, especially on iOS.
I am deeply convinced that UI smoothness is a key parameter of the user experience and has a large impact on the perception of the quality of an application : Google made this statement 3 years ago and responded to the choppiness of its OS with « project butter » introduced in android Jelly Bean. I am also profoundly convinced that the lack of smoothness of Flex mobile (on a large majority of devices) prevents many developers from using it and is an argument for its detractors. Feather UI is a solution, it works perfectly well and is evolving toward something more friendly for Flex developers with the future integration of mxml, but it’s not the swiss knife that flex is… especially for developers who build Flex based RIA with the need of producing a mobile version of their product. I digress a little from the initial subject but we do not say enough how Flex is a fantastic tool. It’s clear that HTML5 is catching up and is well suited for a lot of things but I am not in a hurry to jump in the .js train because it seem’s to me that the existing tools are not stable, not in the sense of execution stability but rather in evolution stability : the joke of « a new .js framework every day » illustrates this constant evolution state of a technology that is not quite ready for the moment when it comes to product large scale applications in optimal conditions. It’s easy to be scared when you follow trends on twitter and feeling like a dinosaur because you continue to use a technology that is less popular than others. I am not against learning a new technology, not at all, but it must be for a good reason and not because the hype is on a particular tool for more than 2 weeks. My job (and I think the job of a lot of people on this list) is not to build dev tools or master 10 langages and 30 frameworks : my job is to build applications to address clients needs, and right now, Flex is the perfect solution. My clients are happy and don’t care about the need of having flash player installed on their computer. Brainless flash haters or allegedly journalists desperate to kill something, because buzz words like kill or dead fills the void of knowledge and objectivity in journalism 5.0, are far less numerous than happy clients and users who don’t care about the engine brand if the engine is powerful… and smooth. This is the reason why I try to optimize flex mobile UI animation. The cacheViewport experiment is not a production ready feature but it clearly shows that there is space for improvements with the current SDK. Modern devices are more suited to run flex mobile (Darkstone, I am very impressed with the results on your device without using the cacheViewport optimization) but how many years will it take before every user device can run any flex mobile project at 60 FPS ? Regarding this experimentation, it’s right that using this technique in the viewport itself rather than in the scroller using the touchInteraction events is definetely not the safer solution : I’m pretty sure that mustella won’t be very happy with the changes I made on the Scroller code even if I tried to make them as light as possible. But like Jude says, having an out of the box « magic button » will be a nice feature for every Flex user. It took me a lot of time to find the most performant blitting approach and to integrate it to the scroller, and during this process I found out that mobile processors are not the only ones responsible for jerky animations : the kinetic of the spark.effects.TrowEffect is far from being perfect (I will try to use the Greensock throwPropsPlugin to see if it’s make a significant difference). Darkstone, « for old smart mobile devices, which have low performance CPUs and GPUs, and small RAMs, your cacheViewport solution is very good for use in low performance CPUs, but the downside is your solution requires a lot memory consumption, which is quite expensive to bear for those old devices » Concerning this downside, it’s true that caching the whole viewport can consume a considerable amount of memory but it should be balanced by the fact that low end devices usually have a low pixel density screen. Nevertheless this technique is definitely not appropriate for cases like lists with a very large number of rows where the contentHeight property can reach dozen of thousands of pixels, not to mention the fact that its initialization will take a very long time because each row will lead to the creation of an item renderer since the layout can't be virtualized. « it seems you don't clear your bitmap cache of the viewport, which I think you should put it into consideration » this is deliberate because the rasterization of the viewport is a costly process (200-300 ms on my device for the content of the demo) and should be done only when necessary, i.e. right before the first scrolling operation or each times the size of the viewport or its content changed. A second process marks as « dirty » every regions of the viewport that are likely to have changed during user interactions and every dirty region is redrawn before the next scrolling operation. I have a problem with this process which is longer than expected even when a small region is redrawn : - The bitmapData.draw call that update the dirty region of the viewport cache is relatively fast (10-25 ms) but it seems to trigger a long phase of displayList rendering that takes up to 200 ms and causes a lag effect during a scroll operation that follows a modification in the UI (for example a switch that is toggled by the user). I don't understand why, so if someone has an idea about that. So to get back to the question of the bitmap cache memory management, each bitmapData tile is not disposed until the next caching operation. I planned to added listeners on the viewport to also call the disposeTiles() method when the viewport is removed from the stage. If someone wants to take a look at the code, it’s very simple : - The spark.components.supportClasses.ViewportCache class implements the IViewport interface and composed two other classes : - The spark.components.supportClasses.ViewportCacheRasterizer class in charge of the rasterization of the viewport and the redrawing of the dirty regions - The spark.components.supportClasses.ViewportCacheDirtRegions class that watches any changes in the viewport and established a map of every dirty region that need to be redrawn A viewPortCache(Boolean) property is added to the scroller class with two additional methods : installViewportCache() and uninstallViewportCache() that are called respectively at the beginning and the end of a scroll operation. Sorry for the long post and the digression :-) -- View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Flex-Scroller-optimization-tp46074p46116.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
