[
https://issues.apache.org/jira/browse/FLEX-34230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976572#comment-13976572
]
Maurice Amsellem commented on FLEX-34230:
-----------------------------------------
ScrollingStageText and StylableStageText maintain a pool of StageText to avoid
allocating a new StageText, if another one with the same characteristics has
been used recently (see internal class StageTextPool in both classes).
the GC issue is caused by this pool, because disabling the pool (that is,
creating a new StageText each time), correctly frees StageText, Skins and
Windows.
I am looking now at what exactly in the pool prevents the GC.
We may also envisage to remove the pool feature if it is not useful anymore.
> StageText skins prevents garbage collection of component with TextInputs and
> TextAreas
> --------------------------------------------------------------------------------------
>
> Key: FLEX-34230
> URL: https://issues.apache.org/jira/browse/FLEX-34230
> Project: Apache Flex
> Issue Type: Bug
> Components: Spark: TextArea, Spark: TextInput
> Affects Versions: Apache Flex 4.12.0
> Reporter: Alexander Scheibe
> Assignee: Maurice Amsellem
> Labels: mobile
> Attachments: MobileTextInputGCTest.fxp
>
>
> In a mobile application with stage text based TextInput and TextArea elements
> garbage collection of sub components (e.g. a view) will not occur until
> another component with the same number of text inputs and text areas is added.
> I would expect the component to be removed from memory (after the next
> garbage collection) when it was removed from its parent.
> I created a demo app where a window with a text input with a
> StageTextInputSkin is opened. Each time the window is opened it will show a
> different number of text inputs (7, 5, 3, 1 and 7 again). Using a memory
> profiler (e.g. Flash Builders memory profiler) will show that the instances
> of the window are kept in memory until the window is opened again with 7 text
> inputs.
> In our real world application this causes a lot of memory to be wasted.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
