Well, TLF might be keeping something around until that last keystroke. If you duplicate the situation with just FTE (more or less) that should tell you if it is the player or other code.
On 11/7/13 1:53 PM, "After24" <[email protected]> wrote: >I think the hypothesis of a memory leak coming from the text layout >framework is not valid. >I thought that it was the fact of entering text in a text input of the >main app that allowed the GC to collect the module but in fact, after >unloading the module, you just have to type something on the keyboard >and the module memory can be released. > >If the module contains a button, the fact of clicking on this button and >then typing something on the keyboard prevents the module from being >garbage collected. > > >Le 05/11/13 23:26, Alex Harui a écrit : >> OK. I think the next test would be to examine the loitering objects in >> the profiler. I think you said you determined the action that causes the >> leak is to type something? If so, then take a memory snapshot before and >> after typing and look to see what is loitering objects and see if they >>are >> being held in by static variables in TLF. >> >> -Alex >> >> On 11/5/13 2:18 PM, "After24" <[email protected]> wrote: >> >>> I have updated the testCase by adding a flash text engine based text >>> field. >>> When this text field is clicked, the text of the TextElement is >>>replaced >>> and the TextLine is updated using the TextBlock.recreateTextLine() >>>method. >>> >>> After this process the module is still garbage collected. >>> >>> https://issues.apache.org/jira/browse/FLEX-338 >>> >>> >>> >>> Le 05/11/13 18:51, Alex Harui a écrit : >>>> I don't think you need to build a whole TextInput. Fundamentally, TLF >>>> just generates TextLines from TextBlocks and recycles them if it can. >>>> I >>>> think the FTE test just has to do some of that. >>>> >>>> -Alex >>>> >>>> On 11/5/13 3:59 AM, "After24" <[email protected]> wrote: >>>> >>>>> Hello Alex, >>>>> >>>>> Creating a TextInput component based on FTE is not an easy task given >>>>> the low level nature of this engine. >>>>> Maybe a framework like TinyTLF which has no dependancies with TLF can >>>>> be >>>>> used to check that the memory leak comes from TLF or FLEX ? >>>>> >>>>> >>>>> >>>>> Le 04/11/13 22:38, Alex Harui a écrit : >>>>>> If you have time to investigate, the next test is to use >>>>>> flash.text.engine >>>>>> classes in an AS-only project. My guess, though, is that there are >>>>>> static >>>>>> variables in Flex and TLF that may be holding onto something. >>>>>> >>>>>> On 11/4/13 1:10 PM, "After24" <[email protected]> wrote: >>>>>> >>>>>>> Until now, my investigations leads me nowhere. My hypothesis is >>>>>>>that >>>>>>> an >>>>>>> object (of the TLF framework) keeps a reference to the textflow of >>>>>>> the >>>>>>> text >>>>>>> input control but I'm really not sure. If someone has an idea of >>>>>>> where >>>>>>> to >>>>>>> search I'm interested. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> >>>>>>> >>>>>>> >>>>>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-manageme >>>>>>>nt >>>>>>> -i >>>>>>> n- >>>>>>> modules-tp3422p3528.html >>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com. >> >
