[webkit-dev] Proposed Timer API

[Chris Marrin]

On Oct 3, 2008, at 1:48 PM, Maciej Stachowiak wrote:
>
> On Oct 3, 2008, at 11:01 AM, Chris Marrin wrote:
>
>>
>> On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
>>>
>>> On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
>>>
>>>> Hi Maciej.
>>>>
>>>> Cameron McCormack:
>>>>>> If possible, it would be nice if there could be some degree of
>>>>>> compatibility between this proposed API and the one in SVG Tiny  
>>>>>> 1.2:
>>>>>>
>>>>>> http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer
>>>>
>>>> Maciej Stachowiak:
>>>>> I considered that, but I don't like the fact that it makes the  
>>>>> common
>>>>> zero-delay continuation callback case into three lines of code
>>>>> instead
>>>>> of one, for what I think is no practical benefit.
>>>>
>>>> Justin’s proposed API seems to need four lines for that case:
>>>>
>>>> var t = new Timer();
>>>> t.repeatCount = 1;
>>>> t.addEventListener('timercomplete', function() { … }, false);
>>>> t.start();
>>>>
>>>> compared with the three for SVG’s timer:
>>>>
>>>> var t = createTimer(0, -1);
>>>> t.addEventListener('SVGTimer', function() { … }, false);
>>>> t.start();
>>>
>>> See my proposal on another thread, which makes this:
>>>
>>> startTimer(0, false, function() { ... });
>>>
>>
>> I really like the idea of a Timer object. It would allow you to  
>> separate creation from starting, allows you to pause and add other  
>> API's to the interface. Can the constructor be used to simplify the  
>> creation:
>>
>>   var t = new Timer(0, false, function() { ...});
>>
>> which would start the timer immediately, as in your example. Or you  
>> could do:
>>
>>   var t = new Timer(function() { ... });
>>   ...
>>   t.startOneShot(1.76);
>
> I don't expect it to be a common use case to create a timer in one  
> place and stop it in another. That being said, you can do this with  
> the API as proposed:
>
> var t = startTimer(0, false, function() { ... });
> t.stop(); // now you have a set up but non-running timer
> ...
> t.restart(); // now it's actually going
>
> I think wanting the timer to start right away is the more common  
> case, so the API is biased in that direction rather than towards  
> initially not running timers.


I think the reason you don't see the pattern of deferred timer  
triggering is because today you just can't do it. I think the use case  
I described (triggering a timer on an animation or media event) will  
be common if and when we have that ability.

In the above example, does the system guarantee that starting a timer  
and immediately stopping it will not ever fire that timer? I can't  
imagine that guarantee being possible, especially for very short (or  
zero) duration timers. If an implementation chooses to queue up timer  
events as soon as they time out (plus the optimization that zero  
duration timers would immediately queue), they would have to dig into  
that queue and rip out any timers that are stopped. And that might not  
even be desirable in many cases. What should happen when a timer times  
out while a JS function is running and you stop it? Should its event  
still run. I'm sure there are many interesting race conditions  
possible here.

It seems like you would avoid these issues if you could have a param  
to startTimer (or a separate createTimer function) that prevented the  
timer from starting in the first place.

-----
~Chris
cmarrin at apple.com