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

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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)

2008-10-03 Thread 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


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

2008-10-02 Thread Maciej Stachowiak

I'm going to send this along to the relevant fora (not sure if it  
should be part of HTML5 or a separate Web Apps WG spec), but here's  
some rough API ideas:


Ridiculously minimalist version:

void callSoon(Function callback);

- Calls the function callback with no arguments the next time  
processing returns to the event loop as if it were a timer ready to  
fire.

To break up work with event processing you'd do:
callSoon(continueFunc);



Fairly minimalist version:

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

interface Timer {
 void stop();
}


- Starts a timer that will call function callback after  
delayInSeconds, which may be a fractional number of seconds. If  
repeating is true, the timer will fire periodically at every  
delayInSeconds. User agents should try to fire timers as close to the  
true delay time as they can, and in particular if the delay is 0 the  
timer should be considered ready to fire on the next return to the  
event loop.


To break up work with event processing you'd do:
startTimer(0, false, continueFunc);



Overengineered version:

Timer createTimer(double firstInterval, double repeatInterval, long  
repeatCount);

interface Timer : EventTarget {
 void stop();
 void start();
 void pause();
 void resume();
 readonly attribute bool isRunning;
 readonly attribute bool isPaused;
 readonly attribute Date startDate;
 double firstInterval;
 double repeatInterval;
 double timeRemaining;
 long repeatCount;
 long repeatsRemaining;
};

- fires event named timer when the timer is ready to fire.

To break up work with event processing you'd do:
var timer = createTimer(0, 0, 1);
timer.addEventListener(timer, continueFunc, false);
timer.start();


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'll probably propose something like the fairly minimalist version to  
HTML5.

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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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)

2008-10-02 Thread 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: 
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html 
 

Regards,
Maciej

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