Re: [webkit-dev] High Resolution Timer API proposal(s)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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