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)
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 t
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
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 startTim
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
On Fri, 03 Oct 2008 19:43:34 +0200, Aaron Boodman <[EMAIL PROTECTED]> wrote:
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
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.
[..
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
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 repeatin
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?:
>> 2) High-resolution timers to be used to precisely drive animation
On Oct 3, 2008, at 4:59 AM, Anne van Kesteren wrote:
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval
- Perhaps the "repeating" or even the
On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
- 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, defaul
On Oct 3, 2008, at 1:40 AM, Geoffrey Garen wrote:
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.
* Di
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 /
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-o
// 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
XMLHt
16 matches
Mail list logo
