<div dir="ltr"><div class="gmail_quote">On Tue, Sep 30, 2008 at 3:08 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div>That seems like incorrect reasoning to me. unclamped setTimeout(0) does not break processing of user events in a single-process browser (I tested). But it will equally drain your laptop battery and produce a great deal of heat and noise with single-process and multiprocess architectures.</div>
</div></div></blockquote><div><br></div><div>Right, which is one reason we don&#39;t run fully-unclamped -- we clamp to 1 ms, and are trying to get anyone other than hyatt to discuss the ramifications of clamping to 3 or 4 ms. &nbsp;I think this proposal solves most of the objections that have been raised, but people still seem more interested in discussing the problems encountered back when WebKit had fully-unclamped timers, which is a different and more risky case.</div>
<div><br></div><div>I certainly do support the proposals for an object-based, higher-resolution timer alongside. &nbsp;But the responsiveness/performance gain from lowering the timer clamp on setTimeout() is noticeable. &nbsp;It&#39;s a real win, which you can see today, on a number of existing sites. &nbsp;There&#39;s an implementation in the field today that can provide data on what the true impact of the change is, both positive and negative.</div>
<div><br></div><div>PK</div></div></div>