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

[Maciej Stachowiak]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/92a04468/attachment-0001.html