W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Proposal: High resolution (and otherwise improved) timer API

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 02 Oct 2008 20:43:55 -0700
To: "public-webapps@w3.org Group WG" <public-webapps@w3.org>
Message-id: <84465E4B-B4BA-4079-8D4D-0EC378CAA42E@apple.com>

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 03:44:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT