On 3/25/10 4:15 PM, P T Withington wrote:
On 2010-03-24, at 18:25, Max Carlson wrote:
Issues:
1) LZNode#2080
//remove __LZconstraintdelegates
// We have to do this to remove LzDataAttrBinds
I don't follow. It seems to me that in LzNode/dataBindAttribute, the
LzDataAttrBind object needs to go on __LZconstraintDelegates, so it can be
applied/unapplied by LzState. But LzDataAttrBind's constructor should register
the binding on __delegates so that it can be auto-cleaned when the node it is
binding is destroyed. We really want to separate these two tasks so future
generations don't have to work this out again. Then you can truly just let
__LZconstraintdelegates drop on the floor in LzNode/destroy.
It turns out removing this has causes Flash10 to show a memory leak - removing
constraint delegates explicitly helps a lot... I wonder why?
It should never be the case that there is a foreign delegate on
__LZconstraintdelegates that is not already on __delegates. Perhaps you could
put some debug code in to see if that is every happening and figure out why?
Yeah, I agree. I didn't see any.
Is is the closure in LzDelegate#register?
if ($as3) {
var a:Array = new Array(m.length);
this.m = function (ignore:*) :* { return m.apply(this, a); }
}
That should only get called if your handler doesn't take the required 1
argument. You would be getting debug warnings if that was being invoked.
Oh, okay.
If this is the case, perhaps we need to track all delegates, at least in as3...
How exactly are you measuring these leaks? It's ok for a delegate that
connects a node to itself to stick around at node destroy time, because they
will get collected when the node itself is (eventually) collected.
I can't tell exactly what's leaking. It's a tiny, tiny amount and could
be the player preallocating objects or something. In any case this
change is a huge improvement. I move to get it checked in as-is and
move forward!
Regards,
Max Carlson
OpenLaszlo.org
