On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote: > > I can appreciate that you aren't interested in revisiting this > problem after having resolved it finally by adding the clamp. I > believe you when you say you had compelling evidence too. >
We are interested in revisiting the problem or we wouldn't be suggesting a new high resolution timer API. We have actually revisited this problem fairly regularly. First we put in the clamp, then I added the scale-up code for nesting so that one-shots get unclamped, and we have been revisiting our Windows timer implementation as well. This is definitely an area that we are open to improving. I myself advocated lowering the clamp back when we first put in the nesting code (but got talked out of it over fear of animation incompatibility rather than CPU hogging). We have hard data that no clamp was bad, since we had problems with top Web sites. We just want to make sure that this accumulated data factors into the decision of what to do. I think people came in a little too strong defending the 1ms clamp, when we had pretty solid data on our side that 1ms would be a problem, and everything got heated from there. It seems to me that the obvious solution is to shift the clamp accounting for computers (and our engine) being faster now. I think we just need to settle on a lower clamp value and make the change. > My point was just that we wanted to feel the pain ourselves before > going a similar route. We have yet to feel the pain substantially, > and so it is interesting to keep going, gathering more data points. > > (Our architecture is designed to allow users to see that it is a > particular website that is "misbehaving" and so we have a lot of > opportunity I think to raise the visibility of things like this and > to at least gather more data.) > I don't know how clear I was in the previous email, but basically it can take a lot of time before you see problems. What happens is a site makes a change, screws up and puts in an unintentional setTimeout loop, and then they pwn the CPU of a browser with no clamp. They don't discover it because every browser has a pretty high clamp. When we had these issues, they'd basically crop up one site at a time every so often. The good news is that usually the sites would fix the problems, but the bad news is it could take a while, and angry users would be switching to Firefox. dave ([EMAIL PROTECTED]) _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
