flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Magnay <nigel.mag...@gmail.com>
Subject Memory Leaking through LayoutManager
Date Thu, 19 Sep 2013 15:31:03 GMT
Hello.

In our code, someone has implemented a custom spark text area, that
attempts to resize based on the number of lines in the text.

Snippet-ish:

<s:TextArea updateComplete="updateCompleteHandler(event)" ... >

...

private function updateCompleteHandler(event:FlexEvent):void {


textFlow.flowComposer.composeToPosition();

var actualNumOfLines: int = textFlow.flowComposer.numLines;

heightInLines = actualNumOfLines;

}


This is then used in a form on a popup. It all works as desired. However,
in trying to track down an enormous memory leak, I think this component
with LayoutManager is responsible.

It seems that if this handler is called - but the component is not on the
screen (it's on the bottom of the popup form, hidden by a scrollbar), then
things go wrong. The

heightInLines = <value>

calls invalidateProperties, which causes the global LayoutManager to add
the component into several priorityqueues. When the dialog is finished,
and I haven't made the control visible (by scrolling) at any point, the
control is still in that priorityqueue (the invalidatePropertiesQueue),
nothing gets released, boom - massive memory leak (which additionally does
not seem to show up in the flex profiler).

Is this a bug? Are there some other rules around cleaning up the layout
manager, or not calling invalidate functions ? Whilst I can work around
this issue in this instance, I'm slightly concerned there are other
instances of controls that are never added which might exhibit the same
behaviour...

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message