[webkit-dev] setTimeout as browser speed throttle
hyatt at apple.com
Tue Sep 30 10:56:56 PDT 2008
On Sep 30, 2008, at 9:37 AM, Mike Belshe wrote:
> Thanks for the concrete examples, Dave! I tested all 3 of these,
> and haven't yet found any problems. But I don't have specific
> URLs. I also looked through the webkit bugs database as much as I
> could, and could not locate them.
When these problems occur they are usually bugs in the Web site that
do (eventually) get discovered and fixed. In the past our evangelism
people have had to contact sites to fix these kinds of issues. This
is why simply surfing to sites doesn't really give an accurate picture
of how this works. In our experience, sites redesign or add new
features (this was the case with Amazon), and the new feature will
have a setTimeout use that wasn't tested in Safari. With no clamp,
we'd end up eating 100% CPU until the site fixed the problem (which
could take months sometimes).
> BTW - if the primary concern is not spinning the CPU, we could just
> drop the throttle down to 2 or 3ms, and the CPU will be largely idle
> on most machines. In a few years, with faster processors, we'll be
> able to drop to 1ms and still have largely idle CPU.
> Would 3ms be viable in your eyes?
Yes, I was considering this also. To me the primary issue with
removing the setTimeout clamp is CPU hogging and not animation speed.
I do think lowering the clamp is reasonable. I still think we should
have an unclamped high res timer API though, regardless of what we
decide with setTimeout.
More information about the webkit-dev