Hey Tink, This was something that was discussed a few times at Adobe. The performance penalty of taking 2 display objects is high, so we thought about making either the SkinnableComponent or the Skin not a DisplayObject. In the end, we didn't have enough time to go about to fully investigate it; however, it's not easy, and it turns out to be really nice that both the Skin and SkinnableComponent are fully-fledge DisplayObjects with their own coordinate space. It is somewhat easier for leaf nodes (GraphicElements) to be non-DisplayObject, but doing it for parent components is a bit trickier. Breaking this model (or faking it) won't be easy, but IMO, it is definitely something worth some investigation.
-Ryan On Tue, Jan 10, 2012 at 4:09 PM, Tink <f...@tink.ws> wrote: > On 10 Jan 2012, at 18:28, Stephane Beladaci wrote: > > What about Spark skinning and performance? Does Spark skinning affects >> or not the performance of an application? I personally really like >> Spark and tend to prefer skins over lose CSS styling, however I heard >> from some colleague that Spark skinning had negative effect on >> performance, I was never able to confirm or not. >> > > One of the issues with Spark skinning was that you would end up with 2 > DisplayObject's for each SkinnableContainer/Component. For mobile > especially, it is good to keep the number of nested DisplayObject's down. > > I brought up the idea some time ago befoe Spark was released that they > should add a getter for "view" on IVisualElement which was typed to > UIComponent. When a child was added its "view" property could be added to > the display list. This would mean that the Skinnable.... classes could free > themselves for being DisplayObject's and return their skins in this getter, > and standard Groups, mx comps etc could return themselves. > > Skinnable.... classes would lose invalidation and it gets somewhat more > complicated if skins are being switch at runtime, but it sounds like this > could be an approach we could investigate here? Maybe I should create a > post with its own topic? > > > Tink > >