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

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

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

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

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

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

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

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?

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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