Hacker News Reader

Comment by jcampbell1 | Hacker News Reader

This is an interesting post. jQuery was fixed to use 13ms as the minimum animation interval a some time ago. This seems like a legit Crome bug to file as the interval should be more deterministic. Chrome shouldn't take a 1ms tick unless it really needs it.

I wonder how much javascript code uses setTimeout(x,0) to push code to the end of the run loop.

View on HN

Initially, Chrome attempted to allow setTimeout()s under the 15ms or so that was standard across browsers, which led to it winning some benchmarks and some accusations of foul play. The intent was pure -- why artificially clamp JavaScript timers to a Windows quirk? -- but eventually Chrome was changed to make timers behave like in other browsers. It appears that the spec now says 4ms is the minimum.

This bug (helpfully linked from MDN) has more of the story. https://code.google.com/p/chromium/issues/detail?id=792

I remember the Chrome timer code of years ago was careful to only adjust the interval when needed. From reading other bugs it looks like today's behavior is an accidental regression and will likely be fixed (until the next time it regresses).

> It appears that the spec now says 4ms is the minimum.

I was playing with Windows timers a little while ago and I noticed that with IE11 open the timer interval sat at 15.6ms, occasionally changing to 4ms while the page was doing things. That was the first time I've heard of a program calling timeBeginPeriod without setting it to 1ms. I hope it catches on.

> I remember the Chrome timer code of years ago was careful to only adjust the interval when needed. From reading other bugs it looks like today's behavior is an accidental regression and will likely be fixed (until the next time it regresses).

Indeed, although it seems the current behavior has been oustanding for some time:

https://code.google.com/p/chromium/issues/detail?id=153139

The original justification for lowering the resolution is an interesting read:

At one point during our development, we were about to give up on using the high resolution timers, because they just seemed too scary. But then we discovered something. Using WinDbg to monitor Chrome, we discovered that every major multi-media browser plugin was already using this API. And this included Flash, Windows Media Player, and even QuickTime. Once we discovered this, we stopped worrying about Chrome's use of the API. After all – what percentage of the time is Flash open when your browser is open? I don't have an exact number, but it's a lot. And since this API effects the system globally, most browsers are already running in this mode.[1]

[1] http://www.belshe.com/2010/06/04/chrome-cranking-up-the-cloc...

It could use requestAnimationFrame in the future, then the js won't need to specify an interval.

https://developer.mozilla.org/en-US/docs/Web/API/window.requ...

Use of requestAnimationFrame triggers high-precision timers in at least Chrome and Firefox...

> I wonder how much javascript code uses setTimeout(x,0) to push code to the end of the run loop.

Probably heaps, but why would that cause the system-wide timer to run more frequently? Even if it does need to it should only be temporary.

Any timer is constrained to the resolution set by the system timer. To go lower one would require something akin to a spin-loop, which defeats any gain by keeping the resolution high.

setTimeout(,0) is a special case. It means "make this function be ran after the current call stack clears". That requires neither a timer nor a spin loop.

If browsers did that they would break the Web. They must clamp to some low delay (4 ms, I believe) or else some pages will lock up.

See https://bugzilla.mozilla.org/show_bug.cgi?id=123273

Right, but that precedent was only set by incorrect implementations existing in the first place. Using setTimeout(,0) recursively in lieu of (a then unavailable) requestAnimationFrame or a non-zero timeout period is in my mind equivalent to while(true){}/infinite tail recursion.

And yes, in the HTML5 spec (years later), it was standardized to a 4ms clamp, also because of the incorrect implementations prior.

Reply on news.ycombinator.com