[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