- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 02 Jul 2011 23:54:43 -0400
- To: public-web-perf@w3.org
On 7/2/11 1:34 PM, Kyle Simpson wrote: > 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? It's done because some pages expect repeated setTimeout(0) to do something "slowly enough" (e.g. scroll a message by that the user can read). That's for foreground tab clamping; background tab is just a matter of preventing web pages the user is not looking at from using resources by accident. > If a tightly running loop doesn't do anything but change values in JS variables > (doesn't affect the DOM/CSS) Defined how? If a script reads/writes properties on the Window, is that affecting 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? This sounds like a very fragile setup to me, where code may or may not get clamped for very mysterious reasons. -Boris
Received on Sunday, 3 July 2011 03:55:11 UTC