I have spent entire day on this bit. And not because it was hard to implement, but because testing other possibilities included porting rendering mechanism back to copyPixel solution. I am still have in back of my mind that bitmap blitting was the most efficient method and keep trying to convince myself how much I was wrong. Again, keep in mind we strictly talking about mobile environment here. And again, whatever I am doing here, you should know this is very experimental approach and mostly because I need some robust structure to port it into molehill in the future. In many specific cases is not recommended to use this stuff instead native display list. At least not yet. There are pro’s and con’s of this solution and I am trying hard to stay on track. However many of rules and discoveries apply to native display list and everyone here, can pick something up for himself. In this same time I am running parallel development of Flaemo framework based on native stuff. Trying to improve as much as I can just in case of failure and testing purposes as a point of reference.

Dynamic FPS ( or if you like framerate throttling)
This is well known technique to manage your frame per second property of the stage. When is not needed keeping it as low as possible. If is needed turn it back to desire level. You can read about this a bit more for example here. To be honest I’ve spent most of the time looking for solution how to completely stop native renderer from work and invalidate it only when I need to sync it with my custom solution. I failed, dealing with Event.RENDER and stage.invalidate() didn’t help to much. Having custom display list it was even harder to find the way around. What I founded out, I didn’t know before, is the fact, that slowing fps rate to 0.01 is not affecting MouseEvent.MOUSE_MOVE at all. Triggering events as a charm with the best speed it can. I was trying to use this feature to force some behaviours but I couldn’t. I am touching stuff here that is just baked deeply into flash player and there is nothing I can do about it. However Dynamic FPS is working and very useful to keep your device cool :). Supported by e.updateAfterEvent() not loosing anything from GUI responsiveness and some other structural changes helped me to improve rendering engine itself about 30%. The fact i am having central event system made up of 4 listeners made implementation very easy and efficient. So this is done here. And can be done using standrad Flash stuff as well witch is MUST HAVE feature for every single application for mobile devices I suppose.

Graphic Sets
Today also I’ve built very first component on top of the custom display list. Button. and quickly realised I need to improve caching system since one object can have multiple drawings and button was the perfect example. So, now you can specify your drawings for every single style set creating new ones ore reusing existing with completely random configuration. Here is the little snippet for how to deal with low level components. By the way, because of Dynamic FPS MobileStats are operating always in real time as default

I was mention before about testing module 80x80px. Today only, for testing purposes I decided to see how far I can go making 4x more elements on the screen after all that improvements. 240 buttons with 3 styles, all dragable and changing it state depend of style being assigned to them not messing up with Signal system that you can use for other purposes. Result? 27 FPS when dragging on my Nexus S. As I said previously I was trying to recreate this test using native list. I have to say it was a bit slower 22fps on the same grid and sort of drawings.

There is also little improvement for FSingal being created only when it’s needed. And you can dispose it after being triggered or be a part of the object in the pool. For components it comes handy for long scrollable lists for example, when you don’t need massive amount of Signals waiting for your finger