[webkit-dev] Proposed Timer API

Maciej Stachowiak mjs at apple.com
Fri Oct 3 13:48:20 PDT 2008


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.

>
> etc.
>
> And you could easily add animation or media API's for synchronization:
>
>    var t = new Timer(1.76, function() { ... }); // when the timer is  
> triggered, it will run for 1.76 seconds
>    var transition = window.getTransitionForElement(element, "left");
>    transition.trigger(t);
>    ...
>    element.style.left = "100px";
>
> This would cause the timer to start when the left transition starts  
> and fire its event 1.76 seconds later.

This doesn't seem very compelling to me. Why not:

element.addEventListener("transitionend", function ()  
{ startTimer(1.76, false, funtion() { ... }, false); } );

Since what a timer is going to do is run script, it doesn't seem like  
a major benefit to avoid running a tiny bit of script to start it.  
Especially if you have to run script to set it up anyway.

  - Maciej


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



More information about the webkit-dev mailing list