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" <vinc...@after24.net> 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" <vinc...@after24.net> 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-management-i
n-
modules-tp3422p3528.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
