[etoys-dev] Timers

[Bert Freudenberg]

On 27.06.2010, at 11:31, Bert Freudenberg wrote:

> On 27.06.2010, at 04:19, Steve Thomas wrote:
> 
>>  at what point does the timer roll over?
> 
> About 300 hours (1073741823 milliseconds) after you reset it to 0.
> 
> 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.

Well not actually "random" as you might have guessed, they simply are not adjusted on loading.

>> 	• 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).

Thinking about it I have an idea that would be even simpler. I won't even create that "timer offset" (which is the only data required for supporting per-objec timers) until you *set* it. That is, looking at the value would not create anything. What you see would be just the number of seconds since starting up Etoys (that's how the underlying Squeak timer works). Only when you set it to another value, the difference between the Squeak timer and the object timer would need to be stored. Hmm, I like that.

Yet simpler would be to have just a global timer on the world without being able to reset it. That would require no state at all.

- Bert -