On Oct 1, 2008, at 5:03 PM, Darin Fisher wrote:
On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:
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.
I'm with Hyatt. The reason we are having this thread is precisely to
revisit the problem.
Good to hear. From what you wrote, I thought you were disinterested
in considering lower clamp values for setTimeout, and that is what I
was referring to. (I knew you supported a high-res timer API.)
From what you say below, however, I see that you are interested in
lowering the clamp value. Sorry for misunderstanding.
I'm interested in finding out whether there is a value lower than 10ms
but higher than 1ms that is (a) safe and (b) beneficial for
performance on real sites. It seems clear to me that 1ms is not safe.
My impression from your remarks was that you thought 1ms is working
fine, and that passively waiting to get more feedback from Chrome
users was an ok way to confirm that it is fine. If that's not what you
meant, then my apologies for misinterpreting. If it is what you meant,
then I continue to respectfully disagree on both fronts.
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.
That is what I was alluding to when I said it took us 3.5 years to
first realize we had to add the clamp. The problems come and go, but
they are consistently a problem, and it can take a while to realize
it.
Yup, I can totally see that happening. This is why I highlighted
our architecture, which helps more squarely place blame on
misbehaving sites. That should help developers and users more
easily see who to blame, which should help these issues get more
visibility and be resolved more quickly. I may be wrong, but I'm
curious to find out.
This seems implausible to me. When a site misrenders, it is obvious
which site is misbehaving, but users still usually blame the browser,
not the site.
Laptops on battery power are not an issue since we wouldn't want to
enable high-res timers on those systems. timeBeginPeriod(1) being
too costly there.
There's no such thing as timeBeginPeriod on Mac or Linux. And I
believe the timeBeginPeriod problem is solvable on Windows (there is
no need to have it on all the time). Overall I think it would be poor
form if site behavior changed depending on whether I was plugged into
a power cable.
Regards,
Maciej
-Darin
However, the bug Mike cited seems to mention problems with the 1ms
limit on some real sites: <http://code.google.com/p/chromium/issues/detail?id=792
>. At least 5 sites are mentioned, including nytimes.
I think we are converging on some good solutions (somewhat lower
basic clamp, new highres API) and I regret if this thread has felt
hostile to anyone.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
