Re: [Efficient Script Yielding] - Clamping

>> Would it be possible to resolve these issues by specifying that if
>> setImmediate() is called raw (that is, not from inside a timer handler),
>> then it basically has no clamping and is ASAP, but if it's called from
>> inside a timer handler (setTimeout, setInterval, setImmediate, etc),
>> then it's ok to clamp it?
>
> How would this differ from setTimeout(..., 0) ?

I was under the impression from previous threads that even the raw (not 
nested) call to setTimeout(..,0) was clamped to happen no sooner than 4ms. 
If that's an accurate statement, then the difference would be that the 
first-level setImmediate() would be able to run un-clamped (subject to the 
UA being able to service the call as soon as possible).

If setTimeout() already runs un-clamped on its first-level call, then I'm 
not sure what all the discussion has been about here, because as I said, it 
seems to me like the 99% use-case for setImmediate() is for first-level 
yields, not for nested/recursive calls for animations.

Another thought (quite possibly off base)... is the clamping done because of 
the inefficiency of a rapidly repeating script making changes to the DOM (or 
styles) and requiring repaints/reflows? If a tightly running loop doesn't do 
anything but change values in JS variables (doesn't affect the DOM/CSS), is 
clamping as necessary? If it's less necessary, perhaps browsers could allow 
the bubble-sort use-case (the yield step in an algorithm) to run un-clamped, 
but if a piece of code affects the DOM/CSS in any way, then clamping kicks 
in?

I dunno, just some thoughts.

--Kyle

Received on Saturday, 2 July 2011 17:35:06 UTC