Re: [Flashcoders] detect and remove listeners

[Ktu]

Have you seen Grant Skinner's Janitor class?

http://gskinner.com/talks/resource-management/ - slide 32 talks about it
click download source at the bottom to get the code.

even this looks interesting:
http://blog.open-design.be/2009/01/29/events-manager-as3-classes/

I just googled AS3 event listener manager and got a few hits.

Ktu


On Wed, Jan 6, 2010 at 4:58 PM, ktt  wrote:

> Thank you all for answers.
> Method with array recording really works nicely :-)
> BTW - while searching for this method I've found other useful listener tips
> too:
>
> http://www.almogdesign.net/blog/actionscript-3-event-listeners-tips-tricks/
>
> --- On Wed, 1/6/10, Taka Kojima  wrote:
>
> > From: Taka Kojima 
> > Subject: Re: [Flashcoders] detect and remove listeners
> > To: "Flash Coders List" 
> > Date: Wednesday, January 6, 2010, 9:02 PM
> > Yeah, that is the best way... that
> > way you can also properly make sure you
> > handle removing all of them when you no longer need an
> > object.
> >
> > You can either create a helper class, with static methods
> > or extend
> > MovieClip or Sprite and have all of your classes extend
> > from the new class.
> >
> > Store everything in a multidimensional array and you're
> > good to go, then you
> > can create a removeAllListeners() method that saves a lot
> > of time and
> > headaches for garbage collection purposes.
> >
> > This is how I handle event listeners for major application
> > components and it
> > has worked very well thus far.
> >
> > - Taka
> >
> > On Wed, Jan 6, 2010 at 3:35 AM, Karl DeSaulniers  >wrote:
> >
> > > Maybe create a class or function that applies and
> > removes the listeners?
> > >
> > > Karl
> > >
> > >
> > >
> > > On Jan 6, 2010, at 5:21 AM, Henrik Andersson wrote:
> > >
> > >  ktt wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> What is the best method to iterate through
> > MovieClip children, check if
> > >>> they have listeners and if they have - remove
> > them?
> > >>>
> > >>>  It is not possible to get a list of the
> > listeners. This means that you
> > >> can not remove them. You can however detect if
> > there is any at all for a
> > >> given event.
> > >> ___
> > >> Flashcoders mailing list
> > >> Flashcoders@chattyfig.figleaf.com
> > >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >>
> > >
> > > Karl DeSaulniers
> > > Design Drumm
> > > http://designdrumm.com
> > >
> > >
> > > ___
> > > Flashcoders mailing list
> > > Flashcoders@chattyfig.figleaf.com
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > ___
> > Flashcoders mailing list
> > Flashcoders@chattyfig.figleaf.com
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
>
>
>
>
> ___
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

[Flashcoders] Repost: how to reduce file size caused by redundant classes in loaded-in movies

[Andrew Sinning]

Sorry about this.  I posted this yesterday, but my inbox has been down 
for the past 3 days and all of my incoming mail appears to have been 
black-holed.


A swf that I am loading in to a parent movie has symbols that are 
linked  to classes that are already available in the parent movie.  This 
is causing the file size of the loaded-in movie to become much larger 
than it would otherwise be.


The problem is that the symbols import classes which import classes 
which import classes and so on.


Without refactoring my entire project, is there something that I can do 
to eliminate the redundant code from the loaded-in swf?


Thanks!


___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

[Flashcoders] Problem with poping up a window

[Lehr, Ross (N-SGIS)]

I'm working with flash 8 and AS2.  I'm loading text from a XML file

If I load open pop in a textbox I 
can access a JavaScript function called "openPop()" in the HTML code of the 
page that loads the. Swf

If I load the same code in a TextArea component, the  no longer calls 
the javascript in the .html page.

Anyone know why?  I cannot find an explanation anywhere.  Let me know if you 
need more details.

Thanks,
Ross
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] hen's teeth...

[John McCormack]

So the performance gains will end up in AS3, sometime:

http://labs.adobe.com/wiki/index.php/Alchemy:FAQ

"Why can't the ActionScript compiler generate byte code that executes as 
quickly as Alchemy?


Compiling with LLVM tools (included as part of Alchemy) allows compile 
and link time optimizations to be applied that the ActionScript compiler 
does not use as yet. In addition, for operations involving ByteArrays 
there are opcodes that are optimized for performance, which the 
ActionScript compiler does not generate today.


The Alchemy team is working closely with the Flash Player and compiler 
teams, and Adobe expects that many if not all of the performance 
improvements from Alchemy will find their way into the shipping 
compilers and players."


John


Meinte van't Kruis wrote:

I was also thinking in the lines of alchemy, and the amazing stuff people
pull of using that.
Seeing the whole apparat project of Joa Ebert or the stuff Nicolas Cannasse
pulls off...

When reading about that, I think a bit of a c++ or even assembler knowledge
would've
helped a great deal, since I'm playing with alchemy a bit myself now as
well.

I realise that stuff isn't found in the average Flash project, allthough I
did work in a project
not too long ago where they are implementing some alchemy to speed things
up.

On Tue, Jan 5, 2010 at 4:07 PM, Paul Andrews  wrote:

  

Meinte van't Kruis wrote:



Actually, I think performance should be on top of the priority list for
any
Flash developer.
Unresponsive flash apps are the number one irritation imho.



  

LOL, I have yet to write one and I have yet to use any techniques from my
assembler or C++ days. In most cases Flash provides more than adequate
responsiveness with very little special care.

The top of the priority list is a user experience that makes the client
happy and performance and responsiveness has yet to be a deciding issue.

The most challenging responsiveness issue I have had has been parsing large
text files for data (several megabytes in size) using AS2 while keeping a
visualisation animating smoothly and preventing script time-outs. It was
very much the rare exception.

I realise that for some people manipulating large numbers of animated clips
or sprites, performance could be an issue, but I think such applications of
flash aren't the mainstream.

Paul

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders






  



___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] hen's teeth...

[Henrik Andersson]

John McCormack wrote:

It looks as if the memory is protected anyway, according to:
http://ncannasse.fr/blog/adobe_alchemy ...

"As a reminder, the Alchemy pipeline is the following : .c file *->*
LLVM intermediate bytecode *->* AVM2 bytecode
However, in general, doing so reduces a lot the performances. Especially
since the abstraction level of the AVM2 bytecode is a lot higher than
the one of the LLVM bytecode, it means that all arbitrary operations
such as pointer and memory manipulation which are done in C must be
/wrapped/ by using the memory-safe mechanisms which are available in
AVM2, such as a |flash.utils.ByteArray| to represent the memory data."

If the AVM2 (Adobe ActionScript™ Virtual Machine 2) does allow
unprotected access, then malicious code could get through via Alchemy or
haXe.
I can't believe that to be true.
Anyway, why would Adobe build it in and not use it?
Strange.


This is what they allow:

function readByteAt(pos) {
if(pos>0 && pos < memSize) {
return globalmemptr[pos];
}
}

You can stop with the wild mass guessing now.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] hen's teeth...

[John McCormack]

It looks as if the memory is protected anyway, according to:
http://ncannasse.fr/blog/adobe_alchemy ...

"As a reminder, the Alchemy pipeline is the following : .c file *->* 
LLVM intermediate bytecode *->* AVM2 bytecode
However, in general, doing so reduces a lot the performances. Especially 
since the abstraction level of the AVM2 bytecode is a lot higher than 
the one of the LLVM bytecode, it means that all arbitrary operations 
such as pointer and memory manipulation which are done in C must be 
/wrapped/ by using the memory-safe mechanisms which are available in 
AVM2, such as a |flash.utils.ByteArray| to represent the memory data."


If the AVM2 (Adobe ActionScript™ Virtual Machine 2) does allow 
unprotected access, then malicious code could get through via Alchemy or 
haXe.

I can't believe that to be true.
Anyway, why would Adobe build it in and not use it?
Strange.

John

Glen Pike wrote:
sandbox? Am guessing direct memory access maybe disallowed because 
people could try to exploit buffer overflows...


John McCormack wrote:

Thank you for that, it was very interesting.
It was certainly faster for those operations.

< opcodes which aren't available in AS3

It doesn't seem possible that those opcodes, for direct memory 
access, are not used by Adobe.

Why would that be?

John



Meinte van't Kruis wrote:

Joa Ebert's apparat can be found here:
http://blog.joa-ebert.com/2009/08/11/apparat-is-now-open-source/
As 
far as
Cannassa is concerned, he is best known for Haxe, which uses alchemy 
opcodes

here and
there(with his flash.memory implementation, but I'm no haxe expert), 
here is

the url:
http://ncannasse.fr/blog/virtual_memory_api

Offcourse it all still runs in the same Flash sandbox, I believe the
performance gains are basically due to
the fact that alchemy compiled code can do memory access faster by 
using

opcodes which arent
available in AS3 (don't ask me why). Anyway, I'm no expert, but a 
bit of it

is explained here:

http://ncannasse.fr/blog/adobe_alchemy

On Wed, Jan 6, 2010 at 12:19 PM, John McCormack 
wrote:




Meinte van't Kruis wrote:


Seeing the whole apparat project of Joa Ebert or the stuff Nicolas
Cannasse



Are their projects available to see?

implementing some alchemy to speed things up.
As far as I understand it, the C++ code is still converted into 
Flash's
byte codes, so any performance gain must have been from the 
algorithms in

the C++ code.

How much difference did it make?

John



On Tue, Jan 5, 2010 at 4:07 PM, Paul Andrews  
wrote:



Meinte van't Kruis wrote:



Actually, I think performance should be on top of the priority 
list for

any
Flash developer.
Unresponsive flash apps are the number one irritation imho.





LOL, I have yet to write one and I have yet to use any techniques 
from my
assembler or C++ days. In most cases Flash provides more than 
adequate

responsiveness with very little special care.

The top of the priority list is a user experience that makes the 
client
happy and performance and responsiveness has yet to be a deciding 
issue.


The most challenging responsiveness issue I have had has been 
parsing

large
text files for data (several megabytes in size) using AS2 while 
keeping a
visualisation animating smoothly and preventing script time-outs. 
It was

very much the rare exception.

I realise that for some people manipulating large numbers of 
animated

clips
or sprites, performance could be an issue, but I think such 
applications

of
flash aren't the mainstream.

Paul

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders








___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders








___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders






___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] hen's teeth...

[Henrik Andersson]

Glen Pike wrote:

sandbox?  Am guessing direct memory access maybe disallowed because
people could try to exploit buffer overflows...

You think that they honestly allows unbounded random memory access? They 
don't. It is restricted to the reservated memory area.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] hen's teeth...

[Glen Pike]

sandbox?  Am guessing direct memory access maybe disallowed because 
people could try to exploit buffer overflows...


John McCormack wrote:

Thank you for that, it was very interesting.
It was certainly faster for those operations.

< opcodes which aren't available in AS3

It doesn't seem possible that those opcodes, for direct memory access, 
are not used by Adobe.

Why would that be?

John



Meinte van't Kruis wrote:

Joa Ebert's apparat can be found here:
http://blog.joa-ebert.com/2009/08/11/apparat-is-now-open-source/
As 
far as
Cannassa is concerned, he is best known for Haxe, which uses alchemy 
opcodes

here and
there(with his flash.memory implementation, but I'm no haxe expert), 
here is

the url:
http://ncannasse.fr/blog/virtual_memory_api

Offcourse it all still runs in the same Flash sandbox, I believe the
performance gains are basically due to
the fact that alchemy compiled code can do memory access faster by using
opcodes which arent
available in AS3 (don't ask me why). Anyway, I'm no expert, but a bit 
of it

is explained here:

http://ncannasse.fr/blog/adobe_alchemy

On Wed, Jan 6, 2010 at 12:19 PM, John McCormack 
wrote:


 

Meinte van't Kruis wrote:

   

Seeing the whole apparat project of Joa Ebert or the stuff Nicolas
Cannasse


  

Are their projects available to see?

 implementing some alchemy to speed things up.
   
  

As far as I understand it, the C++ code is still converted into Flash's
byte codes, so any performance gain must have been from the 
algorithms in

the C++ code.

How much difference did it make?

John



 On Tue, Jan 5, 2010 at 4:07 PM, Paul Andrews  
wrote:
   


 

Meinte van't Kruis wrote:



   
Actually, I think performance should be on top of the priority 
list for

any
Flash developer.
Unresponsive flash apps are the number one irritation imho.





  
LOL, I have yet to write one and I have yet to use any techniques 
from my
assembler or C++ days. In most cases Flash provides more than 
adequate

responsiveness with very little special care.

The top of the priority list is a user experience that makes the 
client
happy and performance and responsiveness has yet to be a deciding 
issue.


The most challenging responsiveness issue I have had has been parsing
large
text files for data (several megabytes in size) using AS2 while 
keeping a
visualisation animating smoothly and preventing script time-outs. 
It was

very much the rare exception.

I realise that for some people manipulating large numbers of animated
clips
or sprites, performance could be an issue, but I think such 
applications

of
flash aren't the mainstream.

Paul

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders








  

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders






  



___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders



--

Glen Pike
01326 218440
www.glenpike.co.uk 

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] hen's teeth...

[John McCormack]

Thank you for that, it was very interesting.
It was certainly faster for those operations.

< opcodes which aren't available in AS3

It doesn't seem possible that those opcodes, for direct memory access, 
are not used by Adobe.

Why would that be?

John



Meinte van't Kruis wrote:

Joa Ebert's apparat can be found here:
http://blog.joa-ebert.com/2009/08/11/apparat-is-now-open-source/
As far as
Cannassa is concerned, he is best known for Haxe, which uses alchemy opcodes
here and
there(with his flash.memory implementation, but I'm no haxe expert), here is
the url:
http://ncannasse.fr/blog/virtual_memory_api

Offcourse it all still runs in the same Flash sandbox, I believe the
performance gains are basically due to
the fact that alchemy compiled code can do memory access faster by using
opcodes which arent
available in AS3 (don't ask me why). Anyway, I'm no expert, but a bit of it
is explained here:

http://ncannasse.fr/blog/adobe_alchemy

On Wed, Jan 6, 2010 at 12:19 PM, John McCormack wrote:

  

Meinte van't Kruis wrote:



Seeing the whole apparat project of Joa Ebert or the stuff Nicolas
Cannasse


  

Are their projects available to see?

 implementing some alchemy to speed things up.

  

As far as I understand it, the C++ code is still converted into Flash's
byte codes, so any performance gain must have been from the algorithms in
the C++ code.

How much difference did it make?

John



 On Tue, Jan 5, 2010 at 4:07 PM, Paul Andrews  wrote:



  

Meinte van't Kruis wrote:





Actually, I think performance should be on top of the priority list for
any
Flash developer.
Unresponsive flash apps are the number one irritation imho.





  

LOL, I have yet to write one and I have yet to use any techniques from my
assembler or C++ days. In most cases Flash provides more than adequate
responsiveness with very little special care.

The top of the priority list is a user experience that makes the client
happy and performance and responsiveness has yet to be a deciding issue.

The most challenging responsiveness issue I have had has been parsing
large
text files for data (several megabytes in size) using AS2 while keeping a
visualisation animating smoothly and preventing script time-outs. It was
very much the rare exception.

I realise that for some people manipulating large numbers of animated
clips
or sprites, performance could be an issue, but I think such applications
of
flash aren't the mainstream.

Paul

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders








  

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders






  



___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders