[gwt-contrib] Re: Why is Timer#schedule(0) bad?

2008-12-10 Thread James Robinson
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?

2008-12-10 Thread Ray Cromwell

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?

2008-12-09 Thread Thomas Broyer


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?

2008-12-08 Thread John Tamplin
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?

2008-12-08 Thread Ray Cromwell

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?

2008-12-08 Thread Bruce Johnson
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?

2008-12-08 Thread Kelly Norton

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
-~--~~~~--~~--~--~---