A

Anonymous

Question

getTimer() accuracy after buttonpress events

Forum|Forum|13 years ago
August 1, 2013
4 replies
972 views

Hi all,

I am planning on conducting a scientific experiment in which timekeeping precision will be very important. The desktop application that I will be using is developed in Adobe AIR and it measures the time between two on-screen button presses. Right now this is done by using getTimer() after the first button is pressed and again getTimer() after the second button is pressed and subtracting the values.

Now I have read some things about the accuracy of the Timer in AS3 and that it is subpar because it depends on performance and framerate (I think) but I am wondering whether in my situation this will be a problem since I only need to measure the time difference once (after the second button press event) which should not require a lot of processing power and thus potential framerate drops.

Can someone (perhaps from Adobe) help me out?

Thanks in advance.

This topic has been closed for replies.

zeh

Inspiring

getTimer() is unrelated to the Timer event I believe. And it'd be bound to the same clock that Date() uses, so I can't see one being different/more precise than the other.

You should be fine. Be sure to use "mouse" events for things (rather than something onenterframe) and it'll be as precise as it gets.

If you *really* need precision, you'd better use a native solution where you can use nanoseconds rather than just miliseconds.

Douglas McCarroll

Inspiring

How precise to you need to be?

While Date and getTimer() are accurate, after the user clicks the button your event listener won't be called until the beginning of the next frame.

Have you read this article? If not, I suggest that you do so:

http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-flash-9-and-avm2/

So, the question becomes whether or not your framerate is fast enough to give you the accuracy you need. The only way to know for sure is to test your app, or a proof-of-concept, on the target machine.

Of course, if you do a proof-of-concept, then add a bunch of functionality to the finished app, that may change things. So, "test early and often".

It's fairly simple to make an ENTER_FRAME listener update a text field with times from, say, the last several hundred enter frame events.

A

Anonymous

Thanks all for your comments!

Douglas McCarroll wrote:
How precise to you need to be?
While Date and getTimer() are accurate, after the user clicks the button your event listener won't be called until the beginning of the next frame.
Have you read this article? If not, I suggest that you do so:
http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-fla sh-9-and-avm2/
So, the question becomes whether or not your framerate is fast enough to give you the accuracy you need. The only way to know for sure is to test your app, or a proof-of-concept, on the target machine.
Of course, if you do a proof-of-concept, then add a bunch of functionality to the finished app, that may change things. So, "test early and often".
It's fairly simple to make an ENTER_FRAME listener update a text field with times from, say, the last several hundred enter frame events.

Douglas: Very interesting article, too bad that no one at Adobe has bothered to comment on whether its correct. I have tested various framerates with both enterframe events and Timer events (set to 1 ms) using a small function that just returns gettimer() differences:

function tmrMethod(evt:Event):void

{

trace("Time diff " + int(getTimer() - prevTime));

prevTime = getTimer();

}

At 30 fps the 1 ms Timer showed the following output on my own machine:

Time diff 37
Time diff 26
Time diff 20
Time diff 20
Time diff 20
Time diff 20
Time diff 20
Time diff 2
Time diff 19
Time diff 1
Time diff 2
Time diff 2
Time diff 4
Time diff 2
Time diff 2
Time diff 2
Time diff 19
Time diff 1
Time diff 2
Time diff 4
Time diff 2
Time diff 2
Time diff 2
Time diff 19
Time diff 1
Time diff 2
Time diff 2
Time diff 4
Time diff 2
Time diff 2
Time diff 2
Time diff 28
Time diff 2
Time diff 2
Time diff 2
Time diff 26
Time diff 2
Time diff 2
Time diff 2
Time diff 32

At 1 fps, however, the 1 ms Timer showed the following output on my own machine:

Time diff 1
Time diff 1
Time diff 1
Time diff 1
Time diff 5
Time diff 5
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 3
Time diff 1
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 36
Time diff 2
Time diff 1
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2
Time diff 2

Interestingly, Timer events seem to benefit from lower framerates, perhaps due to the fact that redraw occurs less often. Given the article, I would expect that this is the same for my button events. So, there would probably be less chance at finding weird differences due to frequent rendering at lower framerates. If this is the case I will reconsider my framerates since all I do is display buttons on screen that don't require frequent updating.

Correct me if I'm wrong though...

E

Eddy_Li

Participating Frequently

Maybe the Date class is more accurate, I'm not sure. Something like,

var start_time:Date, end_time:Date;

var time_difference:Number;

function first_button_press():void{

start_time = new Date();

}

function second_button_press():void{

end_time = new Date();

time_difference = end_time.time - start_time.time; //in milliseconds

}

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.