flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Amsellem <maurice.amsel...@systar.com>
Subject RE: Question about mobile StageText pool
Date Tue, 22 Apr 2014 14:00:51 GMT
> Doing it on removing from stage would not be right in many cases since the widget could
come back on stage later?

I don't know the code well either, and I don't have any definite answer to this question.
So you are probably right to not detach the skin when the widget is removed from stage.

On the other hand, the bulk of  partAdded/partRemoved various implementations are about adding
/ removing event listeners to skin part.

So if it's not called by default,  when do you remove the event listeners when a widget skin
is not in use (ie not on stage)?
This is not consistent, and probably confusing also.

I maybe be wrong, but I would expect the listeners should be removed when the widget and skins
are removed from stage ?


Examples :
1) SkinnableTextBase . partRemoved(partName:String, 
        super.partRemoved(partName, instance);

        if (instance == textDisplay)
            // Stop listening for various events from the IEditableText.
            textDisplay.removeEventListener(SelectionEvent.SELECTION_CHANGE,   textDisplay_selectionChangeHandler);
            textDisplay.removeEventListener(TextOperationEvent.CHANGING,    textDisplay_changingHandler);
            textDisplay.removeEventListener(TextOperationEvent.CHANGE,  textDisplay_changeHandler);
            textDisplay.removeEventListener(FlexEvent.ENTER,   textDisplay_enterHandler);
            textDisplay.removeEventListener(FlexEvent.VALUE_COMMIT,   textDisplay_valueCommitHandler);
        if (instance == promptDisplay)
            var newPromptDisplayProperties:Object = {};
            if (BitFlagUtil.isSet(uint(promptDisplayProperties), 
                newPromptDisplayProperties.prompt = 
            promptDisplayProperties = newPromptDisplayProperties;

2) TitleWindow.partRemoved(partName:String, instance:Object):void
        super.partRemoved(partName, instance);
        if (instance == moveArea)
            moveArea.removeEventListener(MouseEvent.MOUSE_DOWN, moveArea_mouseDownHandler);
        else if (instance == closeButton)
            closeButton.removeEventListener(MouseEvent.CLICK, closeButton_clickHandler);

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : mardi 22 avril 2014 15:12
À : dev@flex.apache.org
Objet : Re: Question about mobile StageText pool

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.


On 4/22/14 4:44 AM, "Maurice Amsellem" <maurice.amsellem@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:
>This is rather weird behavior. Is that expected ?
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@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 
>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.

View raw message