[webkit-dev] High Resolution Timer API proposal(s)

[Mike Belshe]

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 <mjs at apple.com> 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 <public-webapps at w3.org>, 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081003/de612787/attachment.html