incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Frishberg <fri...@gmail.com>
Subject Re: Petition: Flash Catalyst must survive
Date Wed, 11 Jan 2012 04:19:10 GMT
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 <flex@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message