RE: Proposal: High resolution (and otherwise improved) timer API

Mmm. A nice addition to the old timeout properties.

I curious to know more about the use-cases and/or problems underlying the solution you proposed in #2. Would simply extending the current timers to be high-resolution help?:

>> 2) High-resolution timers to be used to precisely drive animations,
with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.



-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Maciej Stachowiak
Sent: Thursday, October 02, 2008 8:44 PM
To: public-webapps@w3.org Group WG
Subject: Proposal: High resolution (and otherwise improved) timer API


Hello Web Apps WG,

A number of WebKit developers (including from the Chrome team and the
Safari team) have been discussing ideas for a new and improved timer
API. We would like to serve the following use cases which we feel are
not well served by the de facto standard (and now HTML5 standard)
interfaces of setTimeout and setInterval:

1) True zero-delay timers, to be used to break up long-running
computations so they can return to the event loop before they
continue, with minimal additional delay. In most browsers, setTimeout
and setInterval have an implied minimum timeout of 10ms or 15.6ms,
meaning they introduce significant delay when used for such purposes.

2) High-resolution timers to be used to precisely drive animations,
with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.

3) Long-lasting timers that may need to have their pending duration
changed before they fire.


We studied the SVGTimer API from SVG Tiny 1.2, and we believe that
interface is not suitable either, because it makes the simple code for
case 1 be three lines instead of one, without adding meaningful extra
benefit in exchange. Here is a rough outline of our proposal:


// should be implemented by Window objects
interface WindowTimer {
     Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}

// starts a timer that will fire in "delayInSeconds" seconds;
"delayInSeconds" may be fractional, and resolution down to at least
milliseconds should be provided, but user agents may provide even
smaller resolution. If delayInSeconds is 0, then the timer should be
considered ready to fire immediately on the next return to the event
loop. If repeating is true, the timer will fire indefinitely every
"delayInSeconds" seconds, until stopped. When the timer fires,
handler's "handleTimer" method is called with the timer object as an
argument.

interface Timer {
     void stop(); // stops the timer, if it still has not fired or if
it is repeating; maybe this should be called "cancel()"

     readonly attribute double timeElapsed; // time in seconds since
the timer was started or since the last time it fired if repeating and
it has already fired at least once

     void restart([Variadic] in double newDelay);
     // if the timer is running it is stopped; then it is restarted
with newDelay as its delay, or the existing delay if newDelay is
omitted; the repeating status
     // and callback will remain the same.
}

[NativeObject] interface TimerHandler {
     void handleTimer(in Timer timer);
}


I think we should put this design or something much like it in a new
standalone spec, possibly also taking on the legacy setTimeout/
setInterval interfaces.

Possible variations discussed:

- Perhaps the delay should be in possibly-fractional milliseconds
rather than possibly-fractional seconds. But expressing microseconds
as fractional milliseconds seems quite weird.

- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval

- Perhaps the "repeating" or even the "delayInSeconds" arguments
should be optional, defaulting to false and 0 respectively, and
possibly in combination with the above suggestion.

- Perhaps there should be separate startTimer and startRepeatingTimer
functions.


I will also note that this interface does not attempt to be fully
general; there's no provision for inspecting a timer's callback
function, for making the first delay be different than the repeat
delay, for making the timer repeat but only a finite number of times,
or anything like that. These did not seem like common enough cases to
warrant bloating the API.


Regards,
Maciej

Received on Friday, 3 October 2008 16:34:31 UTC