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

[Maciej Stachowiak]

On Oct 3, 2008, at 10:09 AM, Mike Belshe wrote:

> 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.

I did consider this possibility, but it is not backwards compatible.  
Many browsers, including WebKit and Gecko based ones, pass any  
arguments to setTimeout past delay to the timeout function. So  
setTimeout(foo, 0.001, false) would call foo with a first parameter of  
false. Since this construct already has a meaning, I don't think we  
can change it for only the boolean case.

I agree with you that excess of APIs can confuse Web developers.  
Normally our preference is to extend existing facilities. Thus the  
WebKit project's focus on extending existing technologies like HTML  
and CSS, as opposed to investing heavily in total reinventions like  
XForms. Not only are ocean-boiling excercises a waste of time for  
authors, but we as browser engine developers will have to continue to  
support the older technologies forever anyway.

In this case, I think the preponderance of the evidence weighs in  
favor of new API, in part because the existing calls are impossible to  
extend compatibly with extra arguments, and because it is likely  
desirable to feature-test for highres timers, and the extra argument  
approach does not allow for that.

Regards,
Maciej

P.S. I encourage further feedback to be sent to public-webapps for  
those who are willing.

>
> 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/741c7b65/attachment.html