<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Peter,<div><br><div><div>On Oct 3, 2008, at 8:36 PM, Peter Kasting wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood <span dir="ltr"><<a href="mailto:jhaygood@reaktix.com">jhaygood@reaktix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div lang="EN-US" link="blue" vlink="purple"> <div><p><span style="font-size:11.0pt;color:#1F497D">I'd say define it as a minimum precision of 1ms, but browser manufacturers can define any precision they wish.</span></p></div></div></blockquote><div><br></div><div>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.</div> <div><br></div><div>I admit that this one worries me a bit.</div></div></div></blockquote><br></div><div>I was going to raise the same issue. Again, I'm wondering how many legitimate uses are there for short timeouts in background tabs/windows. For example, the calendar app sets a timeout minutes, days or hours in the future and those timers could fire in the background. However, for timers set for under 1000 milliseconds, aren't these simply resorting to polling. By inhibiting timers when pages are in the background (especially with new timer APIs), we encourage web application authors to find more appropriate events to key off of. Polling may be a popular design pattern, but we should be thinking of ways to painlessly break that approach, not facilitate it.</div><div><br></div><div>Take care,</div><div>Rob</div></div></body></html>