Building an accurate timekeeper in Flash is not as straight forward as you might think. There are two common ways to track periodic intervals in Actionscript 3. What's not generally well appreciated is that neither of these techniques produce ticks at a consistent rate. The following two examples demonstrate this by calculating 'temporal drift': the cumulative difference between the timer and 'real time'.
Method 1: Listen for new frame events
Using the movie frame rate as a basis for keeping time is unreliable according to Flash Player engineer Tinic Uro. He estimates that frame rates can fluctuate between -10 and +5 frames per second depending upon the demands of the OS and your browser. The example below compares the expected value with the actual value as read from the system clock.
Temporal drift using the movie frame rate method
Method 2: Listen for Timer events
The Timer class in AS3 replaces the setInterval() function from AS2 but despite its name and documented functionality does not produce events consistently at the user defined interval. This rather worrying phenomenon was first noticed by my good friend Tom Coxen. The example below demonstrates the fluctuation in periodicity and the resultant temporal drift.
Temporal drift using the Timer event method
How come no one has noticed this?
Every example you will every find of working with temporal events will by demonstrated by updating some sort of clock display - it's the law. The minimum time interval required to keep a clock updated however is one second; yet these events are commonly generated several times during that period. The reason drift goes unnoticed is quite subtle. The most common response to an event is a call to an update or paint function that creates a new Date object then redraws the clock based on this data.
The rapid re-checking of the system clock ensures the display always shows the correct time. The flaw then, is that this technique works by entirely disassociating the tick event from any calculation of the progress of time. Every time an event occurs, the display is updated straight from the system clock. This works great if all you ever want to display is 'real time' but it won't easily allow you to reliably increment any other temporal counter.
Building a flexible and accurate Timekeeper
For this project I'm going to need an accurate Timekeeper that I can stop and start. I will obviously want to get and set the value of time and I think it would be a lot fun to be able to change the tick frequency and tick duration. This sort of flexibility would allow the viewing of timelines or visualisations at non-real-time speeds. Imagine viewing the cycle of the Earth around the Sun at 1 day per second or the precession of the equinoxes at 1 year per second!
