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

[Aaron Boodman]

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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.

- a
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Ojan Vafai]

On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Darin Fisher]

On Thu, Oct 2, 2008 at 5:32 PM, Ojan Vafai <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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?

-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Ojan Vafai]

On Thu, Oct 2, 2008 at 5:43 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 2, 2008 at 5:32 PM, Ojan Vafai <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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. :)

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Timothy Hatcher]

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 <[EMAIL PROTECTED]> wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Darin Fisher]

On a separate thread, it was discussed that it is useful to support
microsecond resolution for future proofness.
-Darin


On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Maciej Stachowiak]

On Oct 2, 2008, at 5:28 PM, Ojan Vafai wrote:


On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
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);
}


What would you expect the resume() method to do (since there is no  
pause)?




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


I briefly considered cases like that, but I thought it seemed simple  
enough to just cancel the existing timer and start a new one. And it  
seemed uncommon enough to me that it didn't need a direct affordance  
in the API instead of just making a new timer.


 - Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Aaron Boodman]

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> - Starts a timer that will call function "callback" after
> "delayInSeconds", which may be a fractional number of seconds.

It seems safe to assume that a large number of timers are going to be
on the order of 1-10ms. Because of this I think that millisecond units
(which can also be fractional) would be best. It also is nice because
it is consistent with the current API.

- a
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [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  
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Peter Kasting]

On Thu, Oct 2, 2008 at 5:59 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> I briefly considered cases like that, but I thought it seemed simple enough
> to just cancel the existing timer and start a new one. And it seemed
> uncommon enough to me that it didn't need a direct affordance in the API
> instead of just making a new timer.
>

The counter-use case I would have would be wanting to lengthen a timer
that's already running; e.g. you set a timer for 1 second, and at some point
while it's waiting to go off you realize you need to lengthen it to 2
seconds.  If you have to cancel and reset, you also have to track separately
just how much time has elapsed so you know how to do this.

On Thu, Oct 2, 2008 at 6:06 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:

> It seems safe to assume that a large number of timers are going to be
> on the order of 1-10ms. Because of this I think that millisecond units
> (which can also be fractional) would be best. It also is nice because
> it is consistent with the current API.


Most of the setTimeout()/setInterval() calls I saw in surveying the web the
other day were for some round fraction of a second: 0.1, 0.5, 1, or 2
seconds.  I don't think this would change too much.  And fractional seconds
doesn't make my head hurt the way fractional milliseconds does.

PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Ojan Vafai]

On Thu, Oct 2, 2008 at 5:59 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Oct 2, 2008, at 5:28 PM, Ojan Vafai wrote:
>
> On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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);
> }
>
> What would you expect the resume() method to do (since there is no pause)?
>

I guess a better name would be restart? I don't see the need for there to be
a stop and a pause. I realize they are subtley different, but not enough
that it's worth a more complicated API. In short, I would expect
restart/resume to start the timer over, as if a new timer were created.

> 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).
>
> I briefly considered cases like that, but I thought it seemed simple enough
> to just cancel the existing timer and start a new one. And it seemed
> uncommon enough to me that it didn't need a direct affordance in the API
> instead of just making a new timer.
>

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);
}

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Maciej Stachowiak]

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.

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.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Ojan Vafai]

On Thu, Oct 2, 2008 at 6:20 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Aaron Boodman]

On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> Timer startTimer(double delayInSeconds, bool repeating, Function
> callback);
>
> interface Timer {
> void stop();
> }

One other random idea. What about mixing up the param order for
parallelism with the existing timer APIs:

Timer startTimer(Function callback, double delay, bool repeating);

That would make a call look like this:

var timer = startTimer(function() { ... }, 42, true);

Which feels more familiar, but at the same timer better. Less new
things to remember. Also, I think this argues for the unit to continue
being milliseconds, again, for familiarity.

- a
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Alex Iskander]

I agree. "Repeating", it seems to me, should be an optional argument;  
the callback and time, on the other hand, are completely necessary.

The default value for "repeating" is probably up for debate. Would  
more web developers use it for repitition, or for single-use? For high  
resolution purposes (the original purpose of the proposed API), it  
seems more likely to be one use only.

Sent from Alex's iPhone

On Oct 2, 2008, at 8:50 PM, "Aaron Boodman" <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
> wrote:
>> Timer startTimer(double delayInSeconds, bool repeating, Function
>> callback);
>>
>> interface Timer {
>>void stop();
>> }
>
> One other random idea. What about mixing up the param order for
> parallelism with the existing timer APIs:
>
> Timer startTimer(Function callback, double delay, bool repeating);
>
> That would make a call look like this:
>
> var timer = startTimer(function() { ... }, 42, true);
>
> Which feels more familiar, but at the same timer better. Less new
> things to remember. Also, I think this argues for the unit to continue
> being milliseconds, again, for familiarity.
>
> - a
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Aaron Boodman]

On Thu, Oct 2, 2008 at 7:08 PM, Alex Iskander <[EMAIL PROTECTED]> wrote:
> I agree. "Repeating", it seems to me, should be an optional argument; the
> callback and time, on the other hand, are completely necessary.

Good point.

> The default value for "repeating" is probably up for debate. Would more web
> developers use it for repitition, or for single-use? For high resolution
> purposes (the original purpose of the proposed API), it seems more likely to
> be one use only.

I think it usually makes sense to have optional boolean params default
to false, since undefined coerces to false in JS.

- a
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Alex Iskander]

Good point. And although you could change it to "dontRepeat," I don't  
think it would make much sense.

Sent from Alex's iPhone

On Oct 2, 2008, at 9:15 PM, "Aaron Boodman" <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 2, 2008 at 7:08 PM, Alex Iskander <[EMAIL PROTECTED]> wrote:
>> I agree. "Repeating", it seems to me, should be an optional  
>> argument; the
>> callback and time, on the other hand, are completely necessary.
>
> Good point.
>
>> The default value for "repeating" is probably up for debate. Would  
>> more web
>> developers use it for repitition, or for single-use? For high  
>> resolution
>> purposes (the original purpose of the proposed API), it seems more  
>> likely to
>> be one use only.
>
> I think it usually makes sense to have optional boolean params default
> to false, since undefined coerces to false in JS.
>
> - a

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Maciej Stachowiak]

On Oct 2, 2008, at 6:50 PM, Aaron Boodman wrote:

> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
> wrote:
>> Timer startTimer(double delayInSeconds, bool repeating, Function
>> callback);
>>
>> interface Timer {
>>void stop();
>> }
>
> One other random idea. What about mixing up the param order for
> parallelism with the existing timer APIs:
>
> Timer startTimer(Function callback, double delay, bool repeating);
>
> That would make a call look like this:
>
> var timer = startTimer(function() { ... }, 42, true);
>
> Which feels more familiar, but at the same timer better. Less new
> things to remember. Also, I think this argues for the unit to continue
> being milliseconds, again, for familiarity.

The reason I like the other parameters first is that the function  
parameter could plausibly be quite long. Let's say you are writing a  
big continuation function inline, to communicate work in progress via  
lexically visible variables, and let's say maybe even you nest it:

startTimer(function() {
 while (true) {
 //do very important work
 // do even more important work
 }

 if (important)
 work();

 startTimer(function() {
 // do even more important work

 if (doSomethingLater)
 startTimer(function() {

  // stuff to do later

 }, 42, false);

// even stillmore important stuff

 }, 0, false);

}, 0, false);


That seems pretty oogey to me.

On the other hand, I agree (as stated elsewhere in the thread) that  
constantly mentioning false for non-repeating is lame. I think there  
are three ways to deal with that:

1) Reorder the parameters as you have proposed and make the boolean  
optional (perhaps even make the time optional too, defaulting to 0).

2) Keep the parameters in the order I proposed, but make the first  
ones optional - that's a little weird, but not untenable.

3) Split the method into startTimer and startRepeatingTimer.


I think I will mention some of these possible variations when  
proposing the spec. At Hixie's suggestion I will propose it as a  
standalone spec on <[EMAIL PROTECTED]>, I recommend that those who  
wish to follow the discussion subscribe to that list.


Regards,
Maciej






___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Cameron McCormack]

Maciej Stachowiak:
> I think I will mention some of these possible variations when  
> proposing the spec. At Hixie's suggestion I will propose it as a  
> standalone spec on <[EMAIL PROTECTED]>, I recommend that those who  
> wish to follow the discussion subscribe to that list.

Hixie mentioned at one point that he’d like to see WindowTimers in a
separate spec, I think.  Now that there is the event loop stuff in
HTML 5 I don’t know whether that’s still his opinion, but if it is, will
you include setInterval()/setTimeout() in this Web Apps spec?  That
would be useful for SVG in the future.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Maciej Stachowiak]

On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote:

> Maciej Stachowiak:
>> I think I will mention some of these possible variations when
>> proposing the spec. At Hixie's suggestion I will propose it as a
>> standalone spec on <[EMAIL PROTECTED]>, I recommend that those  
>> who
>> wish to follow the discussion subscribe to that list.
>
> Hixie mentioned at one point that he’d like to see WindowTimers in a
> separate spec, I think.  Now that there is the event loop stuff in
> HTML 5 I don’t know whether that’s still his opinion, but if it is,  
> will
> you include setInterval()/setTimeout() in this Web Apps spec?  That
> would be useful for SVG in the future.

I think it would be a good idea to include the older existing timer  
APIs, yes.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Maciej Stachowiak]

On Oct 2, 2008, at 8:19 PM, Maciej Stachowiak wrote:

> I think I will mention some of these possible variations when
> proposing the spec. At Hixie's suggestion I will propose it as a
> standalone spec on <[EMAIL PROTECTED]>, I recommend that those who
> wish to follow the discussion subscribe to that list.

Here it is: 


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Peter Speck]

On 03/10/2008, at 03:50, Aaron Boodman wrote:

> One other random idea. What about mixing up the param order for
> parallelism with the existing timer APIs:
>
> Timer startTimer(Function callback, double delay, bool repeating);
> [...]
> Which feels more familiar, but at the same timer better. Less new
> things to remember. Also, I think this argues for the unit to continue
> being milliseconds, again, for familiarity.


Agree on both terms.   Fractional milliseconds are awkward when coming  
from a Cocoa programming world, but in the html/JS world the basic  
unit of time is milliseconds: the Date object uses milliseconds,  
whereas Cocoa's NSDate uses seconds.

Having the same parameters as current API but with duration in seconds  
rather than milliseconds will create lots of bugs for web-developers.  
That's would be a definite gotcha.


- Peter Speck


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Peter Kasting]

On Thu, Oct 2, 2008 at 10:00 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> Here it is: <
> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html
>  >
>

Thanks for writing this up, Maciej, it looks great to me.

PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Mike Belshe]

Another devil's advocate argument:

Let's fast-forward for a year or two, and the hires timer exists in some
form.  Do we need to offer any protections against CPU spinning?

What if one browser (say the dominant market-leading browser at the time)
implements this with timers that have a 15ms granularity?  Consumers of this
API using a 1ms timer still incur a 15ms delay.  App programmers that don't
test on browsers that do offer hi-res timers will spin the CPU.  Since these
browsers by definition are not market leaders, they'll be forced to
re-introduce the clamp on the new API, and we'll be back where we started.
 Is there a way to avoid repeating history?

Or am I missing something? :-)

Mike





On Thu, Oct 2, 2008 at 8:44 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote:
>
> > Maciej Stachowiak:
> >> I think I will mention some of these possible variations when
> >> proposing the spec. At Hixie's suggestion I will propose it as a
> >> standalone spec on <[EMAIL PROTECTED]>, I recommend that those
> >> who
> >> wish to follow the discussion subscribe to that list.
> >
> > Hixie mentioned at one point that he'd like to see WindowTimers in a
> > separate spec, I think.  Now that there is the event loop stuff in
> > HTML 5 I don't know whether that's still his opinion, but if it is,
> > will
> > you include setInterval()/setTimeout() in this Web Apps spec?  That
> > would be useful for SVG in the future.
>
> I think it would be a good idea to include the older existing timer
> APIs, yes.
>
> Regards,
> Maciej
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Peter Speck]

On 03/10/2008, at 19:09, 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)


And future extensions would add even more parameters.

The Google Map API uses an object for such extra parameters, e.g.

setTimeout("foo()", 0.001, { throttle:false, runInBackground:true });

This would allow for future extensions without adding new methods/ 
classes; without having to add yet another API method.



- Peter Speck


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Justin Haygood]

I'd say define it as a minimum precision of 1ms, but browser manufacturers
can define any precision they wish.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Belshe
Sent: Friday, October 03, 2008 1:24 PM
To: Maciej Stachowiak
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] High Resolution Timer API proposal(s)

 

Another devil's advocate argument:

Let's fast-forward for a year or two, and the hires timer exists in some
form.  Do we need to offer any protections against CPU spinning?

 

What if one browser (say the dominant market-leading browser at the time)
implements this with timers that have a 15ms granularity?  Consumers of this
API using a 1ms timer still incur a 15ms delay.  App programmers that don't
test on browsers that do offer hi-res timers will spin the CPU.  Since these
browsers by definition are not market leaders, they'll be forced to
re-introduce the clamp on the new API, and we'll be back where we started.
Is there a way to avoid repeating history?

 

Or am I missing something? :-)

 

Mike

 

 

 

 

 

On Thu, Oct 2, 2008 at 8:44 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:


On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote:

> Maciej Stachowiak:
>> I think I will mention some of these possible variations when
>> proposing the spec. At Hixie's suggestion I will propose it as a
>> standalone spec on <[EMAIL PROTECTED]>, I recommend that those
>> who
>> wish to follow the discussion subscribe to that list.
>
> Hixie mentioned at one point that he'd like to see WindowTimers in a
> separate spec, I think.  Now that there is the event loop stuff in
> HTML 5 I don't know whether that's still his opinion, but if it is,
> will
> you include setInterval()/setTimeout() in this Web Apps spec?  That
> would be useful for SVG in the future.

I think it would be a good idea to include the older existing timer
APIs, yes.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Peter Kasting]

On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood <[EMAIL PROTECTED]>wrote:

>  I'd say define it as a minimum precision of 1ms, but browser
> manufacturers can define any precision they wish.
>

OK, but that only pushes the problem space outward rather than solving it.
 Make CPUs 10x faster and then have one browser with a floor of 1 ms and one
with 0.1 ms and you have the exact scenario we're in today.  Someone writes
a tight loop in the 1 ms browser, checks that it doesn't use too much CPU,
and pushes the build, and the 0.1 ms browser gets hosed.

I admit that this one worries me a bit.

PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Rob Burns]

Hi Peter,

On Oct 3, 2008, at 8:36 PM, Peter Kasting wrote:

On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood  
<[EMAIL PROTECTED]> wrote:
I'd say define it as a minimum precision of 1ms, but browser  
manufacturers can define any precision they wish.



OK, but that only pushes the problem space outward rather than  
solving it.  Make CPUs 10x faster and then have one browser with a  
floor of 1 ms and one with 0.1 ms and you have the exact scenario  
we're in today.  Someone writes a tight loop in the 1 ms browser,  
checks that it doesn't use too much CPU, and pushes the build, and  
the 0.1 ms browser gets hosed.


I admit that this one worries me a bit.


I was going to raise the same issue. Again, I'm wondering how many  
legitimate uses are there for short timeouts in background tabs/ 
windows. For example, the calendar app sets a timeout minutes, days or  
hours in the future and those timers could fire in the background.  
However, for timers set for under 1000 milliseconds, aren't these  
simply resorting to polling. By inhibiting timers when pages are in  
the background (especially with new timer APIs), we encourage web  
application authors to find more appropriate events to key off of.  
Polling may be a popular design pattern, but we should be thinking of  
ways to painlessly break that approach, not facilitate it.


Take care,
Rob
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Geoffrey Garen]

> Again, I'm wondering how many legitimate uses are there for short  
> timeouts in background tabs/windows.

In a background window:
animation
video
audio
work queues for database or other background processing
something interesting the web hasn't invented yet

To give you some context, Safari used to throttle plug-in timers for  
background windows. The result was that users would see randomly  
choppy content.

In a background tab:
audio
work queues for database or other background processing
something interesting the web hasn't invented yet

Also note that protections for background windows and tabs wouldn't  
solve the majority of the problem we've seen in the wild, which is the  
*foreground* window going crazy in a single-tabbed browsing session.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Chris Marrin]

On Oct 2, 2008, at 5:16 PM, Aaron Boodman wrote:
> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
> 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.
>

I think it's important to have the ability to create the timer without  
starting it (a fourth boolean param?) and then a start() method.

-
~Chris
[EMAIL PROTECTED]




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [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 <[EMAIL PROTECTED]>  
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  
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Maciej Stachowiak]

On Oct 3, 2008, at 10:36 AM, Peter Kasting wrote:

On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood  
<[EMAIL PROTECTED]> wrote:
I'd say define it as a minimum precision of 1ms, but browser  
manufacturers can define any precision they wish.



OK, but that only pushes the problem space outward rather than  
solving it.  Make CPUs 10x faster and then have one browser with a  
floor of 1 ms and one with 0.1 ms and you have the exact scenario  
we're in today.  Someone writes a tight loop in the 1 ms browser,  
checks that it doesn't use too much CPU, and pushes the build, and  
the 0.1 ms browser gets hosed.


I admit that this one worries me a bit.


My proposed requirement was that 0 timers must be processed as soon as  
possible (on the next return to the event loop) and that besides that  
accuracy to at least 1ms should be provided, but more if possible.


I think 0-delay timers are the most interesting use case and the most  
likely to be set to repeat as an author mistake. A repeating  
indefinite 0-delay timer will quite likely hose any browser supporting  
this API per spec, so it shouldn't be a source of future variance  
problems.


I think the use cases for repeating timers with very small but nonzero  
delays will be pretty rare; I doubt many authors specifically want a  
1ms indefinite repeat for instance. So I think the difference between  
1ms and .1ms will be less likely to be a future issue. If we are  
worried, though, we could require a 1ms floor for repeating or nested  
timers after some number of repeats (some largeish number, like 100)  
if we judge that having a crazy-fast repeating timer indefinitely is  
unlikely to be a valid use.


I recommend sending further feedback to public-webapps.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Rob Burns]

Hi Geoff,

On Oct 3, 2008, at 9:04 PM, Geoffrey Garen wrote:

>> Again, I'm wondering how many legitimate uses are there for short  
>> timeouts in background tabs/windows.
>
> In a background window:
> animation
> video

For animation and video, is it necessary even in a completely obscured  
view?

> audio

I only meant to discuss javascript here. Are authors spinning audio  
using javascript setTimeout (I ask naïvely)?

> work queues for database or other background processing

I think this is another example where event listeners or another  
approach entirely would be more legitimate than using timers. Are you  
talking about using setTimout to repeatedly poll to find out if a  
worker is finished? If so, this is definitely not the type of use we  
should facilitate long-term for script timers. Again, exploring these  
questions may lead us to a need to define other events that can  
trigger scripts to run (rather than reliance on polling).

> something interesting the web hasn't invented yet

Given the need to reign in the abuses I don't find this too  
compelling. We wouldn't be preventing innovations, just restricting  
those innovations to run in unburied web pages.

> To give you some context, Safari used to throttle plug-in timers for  
> background windows. The result was that users would see randomly  
> choppy content.

I'm more referring to pages that are completely buried and obscured so  
pages with no need not run at all and users would have no way to know  
they are running choppy.

> In a background tab:
> audio

Again is this being done with javascript? Anyway, I don't think it is  
much to ask of users that they keep tabs unburied to enable listening  
to the embedded audio (or otherwise for browsers to provide an  
interface to re-enable audio within those buried tabs). So authors and  
users do not already have any ingrained preconceptions that audio must  
play even if a tab is buried (and so need to tailor APIs for authors  
to micro-manage this).

> work queues for database or other background processing
> something interesting the web hasn't invented yet

See above.

> Also note that protections for background windows and tabs wouldn't  
> solve the majority of the problem we've seen in the wild, which is  
> the *foreground* window going crazy in a single-tabbed browsing  
> session.

I feel completely the opposite about this. If a foreground window is  
going crazy, that's a problem but a visible problem that even a novice  
user may know how to correct (if it even needs correcting).

However, finding one or a dozen background tabs (amidst tens or  
hundreds) where those tabs contain needlessly running timers (in both  
javascript and elsewhere) is a huge power drain and one whose impacts  
are difficult to access. For mobile users the problem is more obvious,  
but even for desktops, how much wasted energy goes into these cycles  
when repeated across millions (billions?) of processors world-wide  
(and then the air-conditioning that also goes into compensating for  
that needless heat generation)[1]?

Take care,
Rob

[1]: A bit off-topic: say a processor pegged at 20w churns away at  
these wasteful web app cycles for 2 hours each day driving the  
processor from an average of 10% power consumption to 99% power  
consumption. That's 17.8 power dissipation dedicated just to the  
needless cycles or 35.6 w-h energy consumption per day. For one  
billion computers that's 17.8 thousand MW or  35.6 thousand MW-h per  
day or 9256 thousand MW-h per work year. Avoiding something like 17.8  
thousand wasted MW power dissipation (and 9256 thousand MW-hours of  
energy) eliminates the need for dozens of nuclear / coal power  
reactors worldwide (or even dirtier peaker power plants). Considering  
a 1.341 pounds of CO2 per kilowatt-hour (the 1999 estimated rate so  
over-optimistic for world-wide electricity production) that's 12,412  
pounds per year. At 10¢ a kw-h that's $925 million per year in world- 
wide electricity expenses. And that's without calculating compensating  
cooling power consumption, both internal and external to the computing  
device. There's a lot of power (and potential power wasted) in the  
hands of browser developers.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [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.

Minor philosophical digression that I thought of after the fact. One  
of the things I found most unpleasant about Win32 APIs compared to Mac  
OS X and other Unix-like systems is the fact that so many seemingly  
basic calls take so many parameters. And that many of the parameters  
are often structs filled with many mysterious fields, and pointers to  
other structs. That makes figuring out how to do even the most basic  
thing a mystery.

On Mac OS X (from Cocoa to the BSD layer on down), this kind of  
parameteritis is rare, and the same is true of the Web platform. I  
find Cocoa development and Web development more fun than win32  
development, and I think I am not alone in feeling that way. So I fear  
parameteritis more than multiple functions with similar effects.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev