Yes, it cannot be done as fast as the player code. And also, it is often
backwards from what you want. The references pinning an object in memory
is not the calls to addEventListener on that object, but the
addEventListener calls that object made to other objects. Remember:
foo.addEventListener("event", bar.eventHandler) creates a reference from
foo to bar, not the other way around. Foo can still be garbage collected
without calling foo.removeEventListener("event", bar.eventHandler).
But I just had a thought: maybe the goal of this feature isn't to solve
removing event listeners in the framework code, but in the application
developer's code. Maybe we can create a utility class that acts as the
proxy and tracks addEventListener calls. Then it is more pay-as-you-go.
Use it if you really need it but the framework isn't burdened by it.
On 12/9/13 4:38 AM, "Kessler CTR Mark J" <[email protected]> wrote:
>Starling uses their own, but I believe the agreed reason for us not doing
>it was a performance issue. The flash player is running native code at
>something like 40 times more efficient I believe... or at least that was
>what was stated in someone's tests.
>
>-Mark
>
>-----Original Message-----
>From: Kessler CTR Mark J [mailto:[email protected]]
>Sent: Monday, December 09, 2013 7:27 AM
>To: [email protected]
>Subject: RE: Version 4.12 of Apache Flex
>
>Well you can add some redundant code to removeAllListeners if you would
>like, but we can't modify the flash player code. The dispatching
>ultimately gets handled by the player. I made an example[1] a while back
>on duplicating the tracking of the event listeners and ultimately it can
>remove them all. The last updated code for it should be [2] for now.
>
>
>[1] http://people.apache.org/~mkessler/examples/FLEX-33608/app.swf
>[2]
>https://github.com/KesslerConsulting/example/commit/30ee4b96911d301ea09516
>324241c4bc9d734f16
