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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 03 Oct 2008 13:59:18 -0700
To: Travis Leithead <travil@windows.microsoft.com>
Cc: "public-webapps@w3.org Group WG" <public-webapps@w3.org>
Message-id: <08481362-789F-49B4-B7AD-E1525BCC4303@apple.com>


On Oct 3, 2008, at 9:33 AM, Travis Leithead wrote:

> 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?:

I believe it is a Web compatibility problem to completely remove the  
resolution limit from setTimeout and setInterval. Since most sites  
have only been tested on existing browsers that have a floor of 10ms  
or 15.6ms, there are a lot of sites that use values like 0 or 1 but go  
haywire if a browser respects that, but work fine with a 10-15ms  
limit. That was our experience in the past

Unfortunately setTimeout cannot be compatibly extended with extra  
parameters either, because Gecko and WebKit browsers already give a  
meaning to extra parameters past the timeout, namely they are passed  
to the callback function as extra arguments. I believe HTML5 even  
standardizes this. So setTimeout(func, 1, foobar) likely exists in  
code already for any reasonable value of foobar.

This led us to the conclusion that a new API was needed.

Regards,
Maciej

>
>
>>> 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 21:00:00 GMT

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