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

Maciej Stachowiak <mjs@apple.com> wrote:

> 
> 
> On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote:
> 
> >
> > On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak <mjs@apple.com>
> > wrote:
> >>
> >> 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:
> >
> > I don't see anything in the HTML5 document that requires the 10-15.6ms
> > delay. Is HTML5 going to add that as a conformance requirement?
> 
> I don't know. I would recommend to the HTML5 editor to require some
> reasonable minimum because it seems to be de facto required for Web
> compatibility. I cannot state with certainty that nothing lower than
> 10ms is safe. Chrome shipped with a 1ms delay and that was found to
> create problems on a number of sites, including nytimes. They are
> planning to try 4ms next. We would consider using a lower limit in the
> official webkit.org version of WebKit, not not as low as 1ms.

Isn't the problem more that it'll depend on the code being run on the timer
and whether the UA's hardware can cope with running everything fast enough?

We've had trouble with some sites on slow boxes because their interval
timers are constantly wanting to fire before the page has finished reacting
to the previous timer fire.  Our solution has also been to enforce a minimum
frequency for interval timers just to give a fighting chance for the site to
"work" at all (and to not allow the timer to fire again whilst the previous
instance is still executing)


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Monday, 6 October 2008 09:27:45 UTC