Another devil's advocate argument: Let's fast-forward for a year or two, and the hires timer exists in some form. Do we need to offer any protections against CPU spinning?
What if one browser (say the dominant market-leading browser at the time) implements this with timers that have a 15ms granularity? Consumers of this API using a 1ms timer still incur a 15ms delay. App programmers that don't test on browsers that do offer hi-res timers will spin the CPU. Since these browsers by definition are not market leaders, they'll be forced to re-introduce the clamp on the new API, and we'll be back where we started. Is there a way to avoid repeating history? Or am I missing something? :-) Mike On Thu, Oct 2, 2008 at 8:44 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote: > > > Maciej Stachowiak: > >> I think I will mention some of these possible variations when > >> proposing the spec. At Hixie's suggestion I will propose it as a > >> standalone spec on <[EMAIL PROTECTED]>, I recommend that those > >> who > >> wish to follow the discussion subscribe to that list. > > > > Hixie mentioned at one point that he'd like to see WindowTimers in a > > separate spec, I think. Now that there is the event loop stuff in > > HTML 5 I don't know whether that's still his opinion, but if it is, > > will > > you include setInterval()/setTimeout() in this Web Apps spec? That > > would be useful for SVG in the future. > > I think it would be a good idea to include the older existing timer > APIs, yes. > > Regards, > Maciej > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
