[gwt-contrib] Re: Why is Timer#schedule(0) bad?
Maybe a safe default is to clamp to the value of 1 vertical blanking period @ 60hz, or 16ms. It appears that on some systems, the timers are inherently keyed to this resolution anyway. -Ray On Mon, Dec 8, 2008 at 10:09 PM, James Robinson <[EMAIL PROTECTED]> wrote: > WebKit treats a time of 0 as 'set the timer to the lowest legal value'. I'm > not aware of any browsers where it results in the code running inline, that > seems like a clear browser bug if it was the case. The actual value that it > clamps to varies by browser and changes occasionally. > You can actually run into some trouble with a timeout value of 0. This will > always bind to the lowest possible value and can cause excessive CPU > thrashing and laptop battery draining in some browsers. > See > http://lists.macosforge.org/pipermail/webkit-dev/2008-October/005145.html and > http://code.google.com/p/chromium/issues/detail?id=792. > Some apps seem to depend on a certain clamp value existing as well, > although this shouldn't be a problem for GWT. > - James > On Mon, Dec 8, 2008 at 11:45 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote: >> >> On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell <[EMAIL PROTECTED]> >> wrote: >>> >>> I've always assumed that 0 wasn't portable and use 10 by convention. >>> Ideally, you'd want 0 to function like yield(), but I had a nagging >>> suspicious that some browsers might treat 0 as a NOP (that is, run the >>> code immediately without yielding) >> >> Even so, the API method itself should accept 0, I think, and we could just >> round it up to the lowest number acceptable to the browser, such as "time = >> time <=0 ? 10 : time" or something like that. >> > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
WebKit treats a time of 0 as 'set the timer to the lowest legal value'. I'm not aware of any browsers where it results in the code running inline, that seems like a clear browser bug if it was the case. The actual value that it clamps to varies by browser and changes occasionally. You can actually run into some trouble with a timeout value of 0. This will always bind to the lowest possible value and can cause excessive CPU thrashing and laptop battery draining in some browsers. See http://lists.macosforge.org/pipermail/webkit-dev/2008-October/005145.html and http://code.google.com/p/chromium/issues/detail?id=792. Some apps seem to depend on a certain clamp value existing as well, although this shouldn't be a problem for GWT. - James On Mon, Dec 8, 2008 at 11:45 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell <[EMAIL PROTECTED]>wrote: > >> >> I've always assumed that 0 wasn't portable and use 10 by convention. >> Ideally, you'd want 0 to function like yield(), but I had a nagging >> suspicious that some browsers might treat 0 as a NOP (that is, run the >> code immediately without yielding) > > > Even so, the API method itself should accept 0, I think, and we could just > round it up to the lowest number acceptable to the browser, such as "time = > time <=0 ? 10 : time" or something like that. > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
On 9 déc, 07:16, Kelly Norton <[EMAIL PROTECTED]> wrote: > > Chrome: 4ms (fairly recent change) > Safari (mac): 10ms > Safari (win): 15ms > Firefox: 15ms (or 10ms if flash is running) > IE: 15ms > Opera: I have no clue. > > So, that's just a really long way of saying that there is no danger in > allowing 0 and technically it is a perfectly legal value ... it's just > not very useful. I'd add FWIW that HTML5 (pending a split into a distinct spec) defines setTimeout and setInterval as to "asynchronously wait timeout milliseconds and then queue a task [...]" http://www.whatwg.org/specs/web-apps/current-work/multipage/no.html#timers --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
Everone clamps timers now. Chrome launched without a clamp, but even without the clamp setTimeout(..., 0) enqueued an event onto the message loop. There were some old mozilla browsers that didn't yield on setTimeout of 0, but you would probably have to look pretty deep in the archives to find one. Unless things have changed since the last time I looked into this, this is the roll call on timer clamping: Chrome: 4ms (fairly recent change) Safari (mac): 10ms Safari (win): 15ms Firefox: 15ms (or 10ms if flash is running) IE: 15ms Opera: I have no clue. So, that's just a really long way of saying that there is no danger in allowing 0 and technically it is a perfectly legal value ... it's just not very useful. /kel On Mon, Dec 8, 2008 at 11:45 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: >> >> I've always assumed that 0 wasn't portable and use 10 by convention. >> Ideally, you'd want 0 to function like yield(), but I had a nagging >> suspicious that some browsers might treat 0 as a NOP (that is, run the >> code immediately without yielding) > > Even so, the API method itself should accept 0, I think, and we could just > round it up to the lowest number acceptable to the browser, such as "time = > time <=0 ? 10 : time" or something like that. -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > > I've always assumed that 0 wasn't portable and use 10 by convention. > Ideally, you'd want 0 to function like yield(), but I had a nagging > suspicious that some browsers might treat 0 as a NOP (that is, run the > code immediately without yielding) Even so, the API method itself should accept 0, I think, and we could just round it up to the lowest number acceptable to the browser, such as "time = time <=0 ? 10 : time" or something like that. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
I've always assumed that 0 wasn't portable and use 10 by convention. Ideally, you'd want 0 to function like yield(), but I had a nagging suspicious that some browsers might treat 0 as a NOP (that is, run the code immediately without yielding) On Mon, Dec 8, 2008 at 5:21 PM, John Tamplin <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: >> >> Bob and I were just startled to see that you can't set schedule a timer to >> zero: >> >> /** >> >>* Schedules a timer to elapse in the future. >> >>* >> >>* @param delayMillis how long to wait before the timer elapses, in >> >>* milliseconds >> >>*/ >> >> public void schedule(int delayMillis) { >> >> if (delayMillis <= 0) { >> >> throw new IllegalArgumentException("must be positive"); >> >> } >> >> ... >> >> 0 is JavaScript's convention for "do this in the next cycle of the event >> pump." Why are we preventing its use? > > I think I remember something where one of the browsers did something > different on 0. Perhaps Joel or Kelly can confirm that. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Bob and I were just startled to see that you can't set schedule a timer to > zero: > > /** > >* Schedules a timer to elapse in the future. > >* > >* @param delayMillis how long to wait before the timer elapses, in > >* milliseconds > >*/ > > public void schedule(int delayMillis) { > > if (delayMillis <= 0) { > > throw new IllegalArgumentException("must be positive"); > > } > > ... > > 0 is JavaScript's convention for "do this in the next cycle of the event > pump." Why are we preventing its use? > I think I remember something where one of the browsers did something different on 0. Perhaps Joel or Kelly can confirm that. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Why is Timer#schedule(0) bad?
I can't think of a good reason historically. IMO, it's a bug. On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > Bob and I were just startled to see that you can't set schedule a timer to > zero: > > /** > >* Schedules a timer to elapse in the future. > >* > >* @param delayMillis how long to wait before the timer elapses, in > >* milliseconds > >*/ > > public void schedule(int delayMillis) { > > if (delayMillis <= 0) { > > throw new IllegalArgumentException("must be positive"); > > } > > ... > > 0 is JavaScript's convention for "do this in the next cycle of the event > pump." Why are we preventing its use? > rjrjr > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---