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

[Ojan Vafai]

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

> On Oct 2, 2008, at 6:14 PM, Ojan Vafai wrote:
>
>> The thing is that often enough the place where you want to modify the
>> delay you don't necessarily have access to the callback you would need in
>> order to recreate the timer. So, you have to keep track of more stuff in
>> JavaScript (e.g. a pointer to the callback). It's not the end of the world,
>> but it makes for clunkier uses of the API.
>>
>> What do you think of the following?
>>
>> interface Timer {
>>    void stop();
>>    void restart(double optional_argument_delayInSeconds);
>> }
>>
>
> Would restart change the time remaining as if that delay had been set
> originally, or would it make the new delay the current time remaining?
> Should it also let you change the repeating status of the timer? (That
> doesn't seem hugely important but this way seems oddly non-orthogonal).
>
> Perhaps there should be a timeElapsed field (which would give seconds
> actually elapsed since last fire, to the best precision the UA can manage),
> which is useful for both recalculating delays and adjusting for jitter.
>

The way that makes the most sense to me is that restart would make the new
delay the current time remaining.

Having a timeElapsed field seems like a great addition that doesn't bloat
the API.

I really don't see any good use case for letting you change the repeating
status, so I prefer leaving it out.


> I think I will post it to a standards group soon, probably starting with
> whatwg and possibly moving to webapps if Hixie thinks that is the right way
> to go. We can discuss details further there.
>

Sounds good.

This is great. It will make a lot of nasty code much cleaner.

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