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

[Mike Belshe]

I'm not opposed to any of this; and the new API is definitely nicer.  I'll
bring up a devil's advocate point.  One thing I hate is the Microsoft-style
smorgasboard of APIs.  When you want to start a timer, you have 6 to choose
from, and I hope we can avoid similar problems in the DOM.  If keeping the
number of APIs is a worthy goal, we could just augment the existing API in a
backward comaptible way:

    setTimeout(callback, milliseconds, protect_against_cpu_looping = true)

Example to set a 1us timer:

  setTimeout("foo()", 0.001, false)


setInterval could be modified similarly.

There are some downsides; such as difficulty of knowing what resolution your
browser supports; but maybe that is an advantage as well.  You also lose the
new features, and OO style.  But, it does avoid API-soup.

Mike




On Thu, Oct 2, 2008 at 6:07 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 2, 2008, at 5:58 PM, Darin Fisher wrote:
>
> On a separate thread, it was discussed that it is useful to support
> microsecond resolution for future proofness.
>
>
> I proposed seconds so that it was more clear that fractional versions could
> be used, and because specifying microseconds as fractional milliseconds
> seems awkward to me. But whatever the baseline resolution, I think
> fractional values should be supported so there isn't an artificial floor to
> the resolution on future hardware.
>
>  - Maciej
>
>
> -Darin
>
>
> On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher <timothy at hatcher.name>wrote:
>
>> Why double delayInSeconds and not milliseconds to stay consistent?
>>
>> On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:
>>
>> On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <aa at google.com> wrote:
>>
>>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> > I don't really like the overengineered version. I like the "fairly
>>> > minimalist" version best, but is there anything from the
>>> > overengineered version that should be added to it?
>>>
>>> I like the "fairly minimalist" version best as well.
>>>
>>> The stop() method does seem a little lonely on the Timer interface all
>>> by itself.
>>>
>>> If others think any other members from the "overengineered" version
>>> are important I would welcome them to keep stop() company.
>>>
>>
>> +1. My ideal would be the following:
>>
>> Timer startTimer(double delayInSeconds, bool repeating,
>> Function callback);
>>
>> interface Timer {
>>     void stop();
>>     void resume();
>>     void setDelay(double delayInSeconds);
>> }
>>
>> That would cover the majority of cases I've seen in real-world javascript
>> code. The argument for setDelay is wanting to be able to tweak the delay on
>> the fly (e.g. Google Page Creator has autosave code that gets a response
>> from the server  with a longer delay time when the server is overloaded).
>>
>> Ojan
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> 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/fe6b747f/attachment.html