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

Ojan Vafai ojan at chromium.org
Thu Oct 2 17:49:23 PDT 2008

On Thu, Oct 2, 2008 at 5:43 PM, Darin Fisher <darin at chromium.org> wrote:

> On Thu, Oct 2, 2008 at 5:32 PM, Ojan Vafai <ojan at chromium.org> 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).
> That is a good use case.  Adjusting the delay can often be optimized down
> to just re-positioning the already pending timeout in a priority queue.
> Would it make sense for resume and setDelay to be combined as a
> restart(delayInSeconds) method, perhaps where delayInSeconds is an optional
> parameter?

Yes. :)

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

More information about the webkit-dev mailing list