Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > > On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote: > > > > > On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak <[EMAIL PROTECTED]> > > 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
