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 [EMAIL PROTECTED] _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev