Hi-ReS! Stats (Actionscript 3 / Javascript / haXe)

Very nice class indeed, thx !

what means "MS" parameter ?

Milliseconds since the last frame. I have included the definitions on the intro. Thanks :)

perfect! just what I need for my new demo.

Congrats mate :)

Thanks for the useful utility!!

Check out haXe port, http://lists.motion-twin.com/pipermail/haxe/2008-December/021492.html :)

Thanks for the ping. I've added the link to the Download part of the wiki. I've also updated the class to 1.4 :)

It might be worth noting, that adding this will slightly increase your program's memory consumption over time. It's simply because it has constantly running event listeners.

I just spent some time wondering what was eating away memory in my program and noticed that it was this one. The increase is very small though.

Great app!

Are you sure? I re-checked the code, I don't see any reason why it should increase memory consumption per frame... maybe the vars inside the loop?

you code have a bug if remove this but listeners is still run, you must remove all listeners. my fix this code this.addEventListener(Event.REMOVED_FROM_STAGE, onRemovedToStage); private function onRemovedToStage(event:Event):void

{

this.removeEventListener(MouseEvent?.CLICK, onClick); this.removeEventListener(MouseEvent?.MOUSE_OVER, onMouseOver); this.removeEventListener(MouseEvent?.MOUSE_OUT, onMouseOut); this.removeEventListener(Event.ENTER_FRAME, update);

}

Mr Doob: I use FlashDevelop? so I just select a main class to start compiling from. If I make my Main class look like this:

package {

import flash.display.Sprite; import flash.events.Event; import net.hires.debug.Stats;

public class Main extends Sprite {

public function Main():void {

if (stage) init(); else addEventListener(Event.ADDED_TO_STAGE, init);

}

private function init(e:Event = null):void {

removeEventListener(Event.ADDED_TO_STAGE, init); addChild( new Stats() );

}

}

Then if I wait a while, the memory consumption will increase slightly after a while. It probably frees the memory once the garbage collector runs (I didn't wait it out), because that's just how Flash Player works. I just mentioned it so that no one else needs wonder why it behaves that way.

@huihuicn.xu: the component was never designed in that way, like usually you have it or you don't have it. But I think you're right. I'll introduce a destroy() method for cleaning that up

@tuomas.arokanto: Yeah, flash player will start using some memory, and then at some unknown point goes down to, more or less, the starting memory amount.

So I was today profiling this website I'm working on, trying to find a memory leak and the I though it would be cool to have a MAX MEM value on the Stats. So I went ahead and added it.

The interesting thing was that I actually found a memory leak on the Stats itself, very tiny, but easier to spot with 2000 instances of it. To be honest I don't know the reason, it looks like a flash player leak with textfields. But I'm not sure.

As I was working on it I changed the text system and is now XML+CSS based. Performance and filesize is the same, but luckily, now the leak is gone.

All in all, it seemed to me that the versioning had to go to 2.0 as it has been more than a little feature or a little bugfix.

Right now the flash version on rollover is not there, I haven't found it really useful, let me know if you did.

Hopefully it keeps doing the job for what it's for.

For my projects, I added two buttons :

§ one wich allow drag the stats anywhere on the window (usefull when you have something back the stats) § another wich call manualy garbage collector with this : try {

new LocalConnection?().connect('foo'); new LocalConnection?().connect('foo');

it could be idea for the next version !

Does that work on FP9 and FP10? As far as I know there was a method for FP10 that did that already, wasn't it?

Not sure about having version specific things on this little app is what I mean.

Something Tim Knip suggested is to be able to add custom fields. Seemed interesting enough to think about adding it for the 2.2.

Still, it needs to keep being simple, cpuless, and tiny. Somehow :)

Hi, Mr Doob.

It's very important that you mention the memory increase issue at the top of the page. Many people will potentially lose precious time trying to find the source of this problem in their own code, when it's actually an issue with the FPS meter.

About the issue:

If you run the fps meter in a empty movie you can see that the garbage collector is not able to recycle 100% the variables generated during the fps meter operation cycle, and therefore a tiny increase in total memory usage will occur after each clean up.

Since the increase is tiny, I'd classify it as an annoyance rather than a bug, still I suggest you mention it on the page.

Thank you for this wonderful software.

I've done tests of instantiating the stats 1000 times and I wasn't able to spot any memory leak.

Some times the GC doesn't clean 100%, and takes 10 or 20 actions until it goes back to the original memory level.

Thanks!