[etoys-dev] Timers

[Bert Freudenberg]

On 27.06.2010, at 04:19, Steve Thomas wrote:

> Yes useful, has my vote.
> 
> I like that each playfield has its own timer, which allows for multiple timers and that you can reset them.
> 
> 	• Assuming inclusion in the next release for documentation purposes at what point does the timer roll over?

About 300 hours (1073741823 milliseconds) after you reset it to 0.

> 	• Hmmm, I added two playfields and brought watchers for their timers out for display (about 41 seconds apart), then I saved the project and re-opened it and the values before save were about 40 and 81.  On closing Etoys and re-opening the project, the timer values increaded to ~1073635 and 1073686 (still maintaining the 41 second difference, but I saw the numbers jump on open from 40, 81 to the big numbers.

The timers are not reset on project loading. There currently is no overhead to timers.

Unless you use a timer in a script or look at its value, the current value is not computed.

There is a tiny space overhead to store the offset between the timer and real time. It's marginal. But that is why I made only playfield-like objects expose it, rather than showing it for every object.


> 	• On project open do the timers keep their values from last save, it seems that is what happened with TimerTest.001.pr

They get a random value on project load.

> 	• The timers do not seem to start until you open the Viewer and select the category playfield which is seems fine for all object with a playfield category is this the same for World's timer?

In my implementation, timers are created on demand. Only the instant you look at a playfield's viewer is its timer created.

I think I should change the behavior to always start out with a random value. Then it's clear that it's the user's responsibility to reset it to a known value. If they care, that is - e.g. my example project did not need that).

And to answer Subbu's and your follow-up questions:

> Why a timer variable on each playfield as opposed to a timer object?

It's more general, less overhead. You could easily build a timer object in Etoys given the basic functionality I added there.

It fits well with the mouse coordinates I thought.

> The timer object could also be a stopwatch (yes, you could create a variable and set it to the timer value on some event, but a 'stop timer' tile seems simpler). Also, you would only have running intentionally created timers, the current implementation would cause timers to run which could impact performance (albiet minimally).

Behind the scenes there are no individually "running timers". It's using the Squeak timer which is running anyway.

My implementation has no performance overhead whatsoever. Unless you use a timer in a script or look at its value, the current value is not computed.

There is a tiny space overhead to store the offset between the object timer and the Squeak timer. It's marginal. But that is why I made only playfield-like objects expose it, rather than showing it for every object. It's still available for any object. You could actually use the world's timer tile and replace "world" with any object tile to get a per-object timer.

- Bert -