Re: [webkit-dev] Proposed Timer API
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);
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.
-
~Chris
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
Hi Chris.
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.
I think Maciej has made a convincing case that new Timer is a bit
too coy about the fact that the timer is actually starting.
Or you could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
I like your suggestion of adding startOneShot (and
startRepeating?) to the API. I think it would improve clarity over a
bool parameter specifying whether the timer repeats.
To create a Timer that isn't scheduled to fire:
new Timer(...)
To create a Timer that is scheduled to fire:
new Timer(...).startOneShot(...)
new Timer(...).startRepeating(...)
Or, if we don't like constructors:
createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)
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 would be really cool!
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
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
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:
Hi Chris.
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.
I think Maciej has made a convincing case that new Timer is a bit
too coy about the fact that the timer is actually starting.
Or you could do:
var t = new Timer(function() { ... });
...
t.startOneShot(1.76);
I like your suggestion of adding startOneShot (and
startRepeating?) to the API. I think it would improve clarity over
a bool parameter specifying whether the timer repeats.
To create a Timer that isn't scheduled to fire:
new Timer(...)
To create a Timer that is scheduled to fire:
new Timer(...).startOneShot(...)
new Timer(...).startRepeating(...)
It would be pretty unusual for a method like startOneShot or
startRepeating to return a value. I'm not sure if you indended that;
if not
Or, if we don't like constructors:
createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)
We could rename the restart() method to start() (with the same
semantics, or also taking a bool) and have both createTimer() and
startTimer() if we think this use case is very important. I don't
think the need for unstarted timers is very high. However, here's yet
another tricksy way to achieve the same thing:
var tSpec = [0, false, function() {...});
...
var t = startTimer.apply(window, tSpec);
I think setting up a Timer with the intent of not only starting it but
defining the timing parameters is extra useless, since then all it
represents is a function.
Regards,
Maciej
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 would be really cool!
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
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
Re: [webkit-dev] Proposed Timer API
On 3-Oct-08, at 3:01 AM, 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; Just curious - does that mean repeat once or fire once? Seems ambiguous on first glance. I like Maciej's simple proposal better. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
Since our systems are not real-time, saying 'hi-res timer' and 'event
dispatching' together may need some clarification.
Lets say we set delay=0.001 - but not every system can guarantee that the
timer event will fire at precise 1 ms interval. So it can skip a bit or
fire at longer delay, then continue at 1 and so on. Some systems may skip
more then a bit :-) That's why popular way to implement animations is to
request high frequency callback and query hi-res timer from the handler for
actual advance calculation...
The spec could explicitly point that out ('delay' - 'delayAtLeast' ?), and
perhaps recommend to use Date() in the event handler to see what is the
actual time of firing, or have an 'eventTime' property on an Event object.
On a separate note, it almost feels that just adding
invokeAsSoonAsPossible(handler) that is equivalent to unclamped
setTimeout(..., 0) could be all that's needed.
Dmitry
On Wed, Oct 1, 2008 at 9:59 AM, Justin Haygood [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej
Stachowiak
Sent: Wednesday, October 01, 2008 1:02 PM
To: Darin Adler
Cc: WebKit Development
Subject: Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:58 AM, Darin Adler wrote:
On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote:
If you're going to propose a new API designed for hi-res timers, it
ought to use units of microseconds instead of milliseconds.
Or units of seconds, perhaps? Since JavaScript numbers are already
floating point.
That's what I would propose. Then browsers can offer greater precision
in the future without having to redesign the API.
---
Updating now. Units of seconds. Precisision is browser defined, but will be
higher precision (or same precision) as setInterval/setTimeout.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:11 PM, Cameron McCormack wrote: Justin Haygood: http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/ 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 Though I imagine you don’t want to fire events called SVGTimer. :) 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
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();
Or do you mean compared to a simple function-like API, such as
setTimeout(), where it can be done in one line? (Perhaps functions like
setHighResolution{Interval,Timeout}() would be easiest then.)
--
Cameron McCormack ≝ http://mcc.id.au/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
How about a static:
Timer::startTimer(function(),delayInSeconds) ?
--
From: Cameron McCormack [EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 9:01 PM
To: Maciej Stachowiak [EMAIL PROTECTED]
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Proposed Timer API
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();
Or do you mean compared to a simple function-like API, such as
setTimeout(), where it can be done in one line? (Perhaps functions like
setHighResolution{Interval,Timeout}() would be easiest then.)
--
Cameron McCormack ≝ http://mcc.id.au/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Mike On Tue, Sep 30, 2008 at 7:32 PM, Justin Haygood [EMAIL PROTECTED]wrote: http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/ It's based off Adobe's flash.utils.Timer API that they have in AS3. Once I get enough WK comments, I'll see about how to get it to HTML5... --Justin Haygood ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Or units of seconds, perhaps? Since JavaScript numbers are already floating point. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:58 AM, Darin Adler wrote: On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Or units of seconds, perhaps? Since JavaScript numbers are already floating point. That's what I would propose. Then browsers can offer greater precision in the future without having to redesign the API. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, October 01, 2008 1:02 PM To: Darin Adler Cc: WebKit Development Subject: Re: [webkit-dev] Proposed Timer API On Oct 1, 2008, at 9:58 AM, Darin Adler wrote: On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Or units of seconds, perhaps? Since JavaScript numbers are already floating point. That's what I would propose. Then browsers can offer greater precision in the future without having to redesign the API. --- Updating now. Units of seconds. Precisision is browser defined, but will be higher precision (or same precision) as setInterval/setTimeout. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
I first sent this to Mike Belshe; I meant to send it to the list, but I'm new to it: Perhaps it could use milliseconds, but allow floating-point numbers. Milliseconds would be easier, in my opinion, to work with than microseconds. Adobe's data type for delay is Number, which according to their documentation, represents a double-precision floating point number. However, they do not appear to use this precision -- although it is difficult to test; I made a test which, after waiting one second for the application to finish loading, ran a timer set for .1 milliseconds, set to repeat 100 times. The first event was a full millisecond after the timer was called, and the entire repeat (each interval was traced to the debugger) took consistently around 1700 milliseconds. For comparison purposes, I also ran it in a pure loop, and the entire loop took 4 milliseconds. As an aside, a similar test of setInterval on Webkit showed that 100 iterations completed in almost exactly 1000 milliseconds; almost precisely 10 milliseconds per interval. It seemed more consistent than Adobe's. Alex On Oct 1, 2008, at 11:16 AM, Mike Belshe wrote: If you're going to propose a new API designed for hi-res timers, it ought to use units of microseconds instead of milliseconds. Mike On Tue, Sep 30, 2008 at 7:32 PM, Justin Haygood [EMAIL PROTECTED] wrote: http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/ It's based off Adobe's flash.utils.Timer API that they have in AS3. Once I get enough WK comments, I'll see about how to get it to HTML5... --Justin Haygood ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
