[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Re: [bug #22472] textField intsance variables problem

From: Sandro Santilli
Subject: [Gnash-dev] Re: [bug #22472] textField intsance variables problem
Date: Fri, 4 Apr 2008 17:27:00 +0200

On Fri, Apr 04, 2008 at 03:19:33PM +0000, Zou Lunkai wrote:

> Define a textField instance and associate it with variable_a;
> delete variable_a;
> trace(variable_a); // pp give undefined, while gnash doesn't.
> Obviously, the first result is more intuitive, isn't it?
> Bug or compatibility issue, it's debatable here.  Especially if we forget
> about the invalidation problem here(eg. no invalidated bounds checking), the
> solution of this bug is cleaner than the current one in concept. (the
> TextFieldMap has GC or memory overhead I guess, thinking about dead TextField
> instances.)

Yes, it has overhead, and isn't as clean. Overhead should be compared
with those needed to scan the stage tree again for invalidation though.
It seems to me that Udo's design breaks if we can't handle to call
set_invalidate before ...

One thing to look at could be the taht might
be useful for cases like this. Not sure they work like that but
it could be a separate table of "hooks" in the PropertyList
which would be invoked anytime a variable with a given name
would be added/deleted/modified/changed_of_flags.
Such "hook-by-name" support could be also useful for the debugger


reply via email to

[Prev in Thread] Current Thread [Next in Thread]