Re: Proposal: High resolution (and otherwise improved) timer API
Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote: On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: A number of WebKit developers (including from the Chrome team and the Safari team) have been discussing ideas for a new and improved timer API. We would like to serve the following use cases which we feel are not well served by the de facto standard (and now HTML5 standard) interfaces of setTimeout and setInterval: I don't see anything in the HTML5 document that requires the 10-15.6ms delay. Is HTML5 going to add that as a conformance requirement? I don't know. I would recommend to the HTML5 editor to require some reasonable minimum because it seems to be de facto required for Web compatibility. I cannot state with certainty that nothing lower than 10ms is safe. Chrome shipped with a 1ms delay and that was found to create problems on a number of sites, including nytimes. They are planning to try 4ms next. We would consider using a lower limit in the official webkit.org version of WebKit, not not as low as 1ms. Isn't the problem more that it'll depend on the code being run on the timer and whether the UA's hardware can cope with running everything fast enough? We've had trouble with some sites on slow boxes because their interval timers are constantly wanting to fire before the page has finished reacting to the previous timer fire. Our solution has also been to enforce a minimum frequency for interval timers just to give a fighting chance for the site to work at all (and to not allow the timer to fire again whilst the previous instance is still executing) -- Stewart Brodie Software Engineer ANT Software Limited
Re: Proposal: High resolution (and otherwise improved) timer API
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
How about a Timer constructor function instead?
Pros:
* Fits the object-oriented programming model of new Image, new
XMLHttpRequest, etc.
* Enables use of object-oriented features like instanceof,
the .constructor property, and prototype-based extensions to timer
objects.
* Distinguishes itself better from the old setTimeout / setInterval
functions.
readonly attribute double timeElapsed; // time in seconds since
elapsedTime reads better to me, since it makes elapsed definitely
an adjective, and not a verb.
Overall, I think this is a great proposal.
Cheers,
Geoff
Re: Proposal: High resolution (and otherwise improved) timer API
On Oct 3, 2008, at 12:03 AM, Geoffrey Garen wrote:
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
How about a Timer constructor function instead?
Pros:
* Fits the object-oriented programming model of new Image, new
XMLHttpRequest, etc.
* Enables use of object-oriented features like instanceof,
the .constructor property, and prototype-based extensions to timer
objects.
* Distinguishes itself better from the old setTimeout / setInterval
functions.
In general, the DOM does not depend on a constructor as the only way
to create a kind of object, since it is nominally language-agnostic.
In fact, for most things it doesn't provide a constructor invokable as
such at all; you listed some of the few exceptions.
In addition, new Timer(...) does not as clearly express the fact
that the timer is not only created but started right away. So I don't
think a constructor would be good as the sole interface for starting a
timer.
readonly attribute double timeElapsed; // time in seconds since
elapsedTime reads better to me, since it makes elapsed
definitely an adjective, and not a verb.
Good suggestion.
Regards,
Maciej
Re: Proposal: High resolution (and otherwise improved) timer API
Pros: * Fits the object-oriented programming model of new Image, new XMLHttpRequest, etc. * Enables use of object-oriented features like instanceof, the .constructor property, and prototype-based extensions to timer objects. * Distinguishes itself better from the old setTimeout / setInterval functions. In general, the DOM does not depend on a constructor as the only way to create a kind of object, since it is nominally language-agnostic. In fact, for most things it doesn't provide a constructor invokable as such at all; you listed some of the few exceptions. A Timer constructor is language-agnostic as long as you specify that new Timer() and Timer() behave the same way. Other JavaScript constructor APIs, like Array, behave this way. The fact that most things in the DOM aren't instantiated by constructors is really just an accidental consequence of the fact that they're available as properties of the document, and it makes no sense to create them standalone. The two qualities are not found in timers. In addition, new Timer(...) does not as clearly express the fact that the timer is not only created but started right away. So I don't think a constructor would be good as the sole interface for starting a timer. That seems like a minor criticism, relative to the pros above. Besides, we all know that if this API becomes standardized, Mozilla is going to add a global Timer constructor, just like they did for all the other classes in the DOM. And we all know that WebKit will follow suit. So why not get a jump start on things, and specify it that way from the beginning? I guess we could make a Timer constructor that threw when you called it, as we did with node-related DOM constructors, but that behavior is really weird. Geoff
Re: Proposal: High resolution (and otherwise improved) timer API
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: A number of WebKit developers (including from the Chrome team and the Safari team) have been discussing ideas for a new and improved timer API. [...] I think we should put this design or something much like it in a new standalone spec, possibly also taking on the legacy setTimeout/ setInterval interfaces. Note that this group has some minimal but important process requirements before it takes on a spec (see the charter[1]). The first step (finding someone who agrees to do the editing work - otherwise this won't happen) is now underway in the Working Group... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://www.opera.com
Re: Proposal: High resolution (and otherwise improved) timer API
On Oct 3, 2008, at 1:25 PM, Charles McCathieNevile wrote: On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: A number of WebKit developers (including from the Chrome team and the Safari team) have been discussing ideas for a new and improved timer API. [...] I think we should put this design or something much like it in a new standalone spec, possibly also taking on the legacy setTimeout/ setInterval interfaces. Note that this group has some minimal but important process requirements before it takes on a spec (see the charter[1]). The first step (finding someone who agrees to do the editing work - otherwise this won't happen) is now underway in the Working Group... Ian Hickson mentioned that he has a possible candidate editor for this spec. I am also willing to edit or co-edit myself. Regards, Maciej
Re: Proposal: High resolution (and otherwise improved) timer API
On Oct 3, 2008, at 9:33 AM, Travis Leithead wrote:
Mmm. A nice addition to the old timeout properties.
I curious to know more about the use-cases and/or problems
underlying the solution you proposed in #2. Would simply extending
the current timers to be high-resolution help?:
I believe it is a Web compatibility problem to completely remove the
resolution limit from setTimeout and setInterval. Since most sites
have only been tested on existing browsers that have a floor of 10ms
or 15.6ms, there are a lot of sites that use values like 0 or 1 but go
haywire if a browser respects that, but work fine with a 10-15ms
limit. That was our experience in the past
Unfortunately setTimeout cannot be compatibly extended with extra
parameters either, because Gecko and WebKit browsers already give a
meaning to extra parameters past the timeout, namely they are passed
to the callback function as extra arguments. I believe HTML5 even
standardizes this. So setTimeout(func, 1, foobar) likely exists in
code already for any reasonable value of foobar.
This led us to the conclusion that a new API was needed.
Regards,
Maciej
2) High-resolution timers to be used to precisely drive animations,
with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Maciej Stachowiak
Sent: Thursday, October 02, 2008 8:44 PM
To: public-webapps@w3.org Group WG
Subject: Proposal: High resolution (and otherwise improved) timer API
Hello Web Apps WG,
A number of WebKit developers (including from the Chrome team and the
Safari team) have been discussing ideas for a new and improved timer
API. We would like to serve the following use cases which we feel are
not well served by the de facto standard (and now HTML5 standard)
interfaces of setTimeout and setInterval:
1) True zero-delay timers, to be used to break up long-running
computations so they can return to the event loop before they
continue, with minimal additional delay. In most browsers, setTimeout
and setInterval have an implied minimum timeout of 10ms or 15.6ms,
meaning they introduce significant delay when used for such purposes.
2) High-resolution timers to be used to precisely drive animations,
with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.
3) Long-lasting timers that may need to have their pending duration
changed before they fire.
We studied the SVGTimer API from SVG Tiny 1.2, and we believe that
interface is not suitable either, because it makes the simple code for
case 1 be three lines instead of one, without adding meaningful extra
benefit in exchange. Here is a rough outline of our proposal:
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
// starts a timer that will fire in delayInSeconds seconds;
delayInSeconds may be fractional, and resolution down to at least
milliseconds should be provided, but user agents may provide even
smaller resolution. If delayInSeconds is 0, then the timer should be
considered ready to fire immediately on the next return to the event
loop. If repeating is true, the timer will fire indefinitely every
delayInSeconds seconds, until stopped. When the timer fires,
handler's handleTimer method is called with the timer object as an
argument.
interface Timer {
void stop(); // stops the timer, if it still has not fired or if
it is repeating; maybe this should be called cancel()
readonly attribute double timeElapsed; // time in seconds since
the timer was started or since the last time it fired if repeating and
it has already fired at least once
void restart([Variadic] in double newDelay);
// if the timer is running it is stopped; then it is restarted
with newDelay as its delay, or the existing delay if newDelay is
omitted; the repeating status
// and callback will remain the same.
}
[NativeObject] interface TimerHandler {
void handleTimer(in Timer timer);
}
I think we should put this design or something much like it in a new
standalone spec, possibly also taking on the legacy setTimeout/
setInterval interfaces.
Possible variations discussed:
- Perhaps the delay should be in possibly-fractional milliseconds
rather than possibly-fractional seconds. But expressing microseconds
as fractional milliseconds seems quite weird.
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
Re: Proposal: High resolution (and otherwise improved) timer API
On Oct 3, 2008, at 10:43 AM, Aaron Boodman wrote:
Hi Maciej,
Thanks for raising this. It's a good addition to the web platform. I'm
definitely +1 to the idea.
2008/10/2 Maciej Stachowiak [EMAIL PROTECTED]:
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
- Perhaps the delay should be in possibly-fractional milliseconds
rather than possibly-fractional seconds. But expressing
microseconds as fractional milliseconds seems quite weird.
To me, fractional milliseconds does not seem weird. On the webkit-dev
thread, Peter Speck pointed out [1] that the unit of time in web
development is milliseconds. Dates are in milliseconds, setTimeout
takes millisecond arguments, etc. So to me, it would be weird to have
a new timer API that suddenly uses seconds. And I tend to agree with
Peter that doing so would be a common source of bugs for web
developers.
I find the fact that Dates are in milliseconds convincing. It should
be in milliseconds so people can reasonably do math with Dates and
elapsedTime.
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
- Perhaps the repeating or even the delayInSeconds arguments
should be optional, defaulting to false and 0 respectively, and
possibly in combination with the above suggestion.
You mentioned [2] that this is a bit weird because the function can be
quite long and then it reads poorly for anonymous functions.
I see your point, but we already have that problem with setTimeout and
setInterval. And I feel like it's more important to have consistency
where possible with these well-established APIs than fix this issue.
I don't think consistency on argument order is critical, but I see
your point. We won't be 100% copying the argument order anyway since I
don't think it is worth carrying over the quirky extra argument
behavior of setTimeout and setInterval.
Regards,
Maciej
Re: Proposal: High resolution (and otherwise improved) timer API
On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: A number of WebKit developers (including from the Chrome team and the Safari team) have been discussing ideas for a new and improved timer API. We would like to serve the following use cases which we feel are not well served by the de facto standard (and now HTML5 standard) interfaces of setTimeout and setInterval: I don't see anything in the HTML5 document that requires the 10-15.6ms delay. Is HTML5 going to add that as a conformance requirement? - Rob
Proposal: High resolution (and otherwise improved) timer API
Hello Web Apps WG,
A number of WebKit developers (including from the Chrome team and the
Safari team) have been discussing ideas for a new and improved timer
API. We would like to serve the following use cases which we feel are
not well served by the de facto standard (and now HTML5 standard)
interfaces of setTimeout and setInterval:
1) True zero-delay timers, to be used to break up long-running
computations so they can return to the event loop before they
continue, with minimal additional delay. In most browsers, setTimeout
and setInterval have an implied minimum timeout of 10ms or 15.6ms,
meaning they introduce significant delay when used for such purposes.
2) High-resolution timers to be used to precisely drive animations,
with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.
3) Long-lasting timers that may need to have their pending duration
changed before they fire.
We studied the SVGTimer API from SVG Tiny 1.2, and we believe that
interface is not suitable either, because it makes the simple code for
case 1 be three lines instead of one, without adding meaningful extra
benefit in exchange. Here is a rough outline of our proposal:
// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}
// starts a timer that will fire in delayInSeconds seconds;
delayInSeconds may be fractional, and resolution down to at least
milliseconds should be provided, but user agents may provide even
smaller resolution. If delayInSeconds is 0, then the timer should be
considered ready to fire immediately on the next return to the event
loop. If repeating is true, the timer will fire indefinitely every
delayInSeconds seconds, until stopped. When the timer fires,
handler's handleTimer method is called with the timer object as an
argument.
interface Timer {
void stop(); // stops the timer, if it still has not fired or if
it is repeating; maybe this should be called cancel()
readonly attribute double timeElapsed; // time in seconds since
the timer was started or since the last time it fired if repeating and
it has already fired at least once
void restart([Variadic] in double newDelay);
// if the timer is running it is stopped; then it is restarted
with newDelay as its delay, or the existing delay if newDelay is
omitted; the repeating status
// and callback will remain the same.
}
[NativeObject] interface TimerHandler {
void handleTimer(in Timer timer);
}
I think we should put this design or something much like it in a new
standalone spec, possibly also taking on the legacy setTimeout/
setInterval interfaces.
Possible variations discussed:
- Perhaps the delay should be in possibly-fractional milliseconds
rather than possibly-fractional seconds. But expressing microseconds
as fractional milliseconds seems quite weird.
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
- Perhaps the repeating or even the delayInSeconds arguments
should be optional, defaulting to false and 0 respectively, and
possibly in combination with the above suggestion.
- Perhaps there should be separate startTimer and startRepeatingTimer
functions.
I will also note that this interface does not attempt to be fully
general; there's no provision for inspecting a timer's callback
function, for making the first delay be different than the repeat
delay, for making the timer repeat but only a finite number of times,
or anything like that. These did not seem like common enough cases to
warrant bloating the API.
Regards,
Maciej
