Don't know this code that well, but when would you trigger detaching of the skin? Doing it on removing from stage would not be right in many cases since the widget could come back on stage later.
-Alex On 4/22/14 4:44 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >Digging further into TextInput code, I made some curious findings (at >least for me): > >StageText is not GCed because StyleableStageText sets event listeners on >changing, change, enter, events etc... when the skin is attached (in >TextInputBase partAdded). >2) these event listeners should be removed when the skin is detached and >partRemoved is called, but *partRemoved is never called*, >=> this explains why TI and TI window are not gced, they are locked by >SST event listeners, which are themselves locked by the SST pool. > >Stepping through the code, it appears that detachSkin & partRemoved are >called only if mx_internal::skinDestructionPolicy is set to "auto" (it's >set to "never" by default). > >I made a small desktop testing app, and tested it with SDK 4.12 and even >SDK 4.6 => detachSkin & partRemoved are never called by default. > >It seems that this is not a new problem: >http://stackoverflow.com/questions/8150934/spark-skinnablecomponent-skinde >structionpolicy > >This is rather weird behavior. Is that expected ? > >Thoughts? > >Maurice > >-----Message d'origine----- >De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >Envoyé : mardi 22 avril 2014 11:23 >À : dev@flex.apache.org >Objet : Question about mobile StageText pool > >Hi team, > >I have been working on FLEX-34230 (StageText skins prevents garbage >collection of component with TextInputs and TextAreas) and it appears >that GC is prevented by the internal pool of StageText used in >StageText-based skins (precisely in old StyleableStageText and new >ScrollableStageText). > >Apparently, the purpose of this cache pool is to avoid creating a new >StageText if one with the same characteristics is already in the pool >(and returning that one). > >Does someone know why this pool has been introduced ? is it to improve >performance because StageText allocation is slow ? > >I mean, maybe if the reason for it is not valid anymore, the easiest way >to fix that would be simply to remove the pool, and create a new >StageText everytime time one is needed. > > > >Maurice
