On Sep 30, 2008, at 6:37 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
It seems to these are demo pages, tutorials, or descriptions of
techniques. Clearly tutorials and demos can adapt to a new API, and
improving their current form is not much of a benefit. How about
real existing sites that benefit?
You're right; my list sucked. I thought we had a list of sites that
were helped that led us to do this and posted assuming that without
checking. I shouldn't have asserted something I hadn't verified,
and I should have said so immediately afterwards. I'm sorry.
I think our original motivation was that we wrote some code very
like the benchmarks Mike posted to start this thread, and found
things were unexpectedly slow. We hadn't realized there'd be a
minimum value on setTimeout() since there wasn't a spec that said
that and it wasn't intuitive that there should be one; if we had
made this mistake, surely others would have, so we wondered if we
could improve things for people in general. When we considered
lowering it we worried quite a bit about web compat, but were unable
to find any problems in several months of daily usage, or in our
explicit testing of all the related sites we could find from old
WebKit bugs about this. And since launch I believe we still haven't
seen problems of sites intentionally using setTimeout(0) and having
difficulties; the one problem I'm aware of involves double-inclusion
of a script that leads to an orphaned timer spinning in the
background. But I'm not sure, maybe there have been other cases we
know of.
I still think this is the right thing to do, though I don't seem to
have any convincing evidence for it. Darin's comments on bug 6998,
or John Resig's comments on his blog post about Chromium's behavior
here, or Hyatt's comments earlier in this thread, echo parts of my
feelings, which are: authors should be able to get called back
"ASAP" when they do this, where "ASAP" is subject to the limits of
the platform, not burning 100% of the CPU, etc. I assume there are
sites out there that legitimately benefit from our changes, but I
think we made our decision before having such a list.
So I am sorry for being so forceful with this opinion previously and
that I don't have good data to support it. We (the Chromium folks)
want to help make the web better and it seems like we've been
getting off on the wrong foot a lot lately in broader WebKit
discussions, but I hope you will still consider our opinions
seriously. Sometimes we have acted on instinct, theory, and limited
data, but I'm not sure that that means all of those decisions have
been wrong.
That's ok, we are used to some forceful assertion of opinions in the
WebKit community. :-) As long as we can ultimately come to a good
resolution, it's ok if the discussion goes off on some tangents.
Indeed, I think a lot of good ideas and information have come up in
this thread, and I am glad that we had this discussion. This list
should be a safe space for freewheeling (but respectful) technical
discussions.
But on the other hand, In the history of WebKit development we have a
strong tradition of using data, measurements and testing to evaluate
changes, particularly in the areas of performance, memory use and Web
compatibility. Our experience with performance especially is that
improvements based on guesswork or instinct rather than measurement
tend to be ineffective. One advantage of data and measurements is that
they tend to be easier for a heterogenous organization to agree on
than theories or instincts.
I agree with you that web content authors should have a way to get
called back ASAP. It seems like we have three different proposals
identified that most have agreed are worth pursuing:
1) Design an improved timer API that is object-oriented and supports
high resolution, with no artificial lower limit. Propose for HTML5,
implement in WebKit, encourage other browser vendors to implement it.
Am I right that there's rough consensus we should do this? If so, I
can circulate a rough cut proposal on this list, and then move
discussion of this idea to the WHATWG.
2) Consider making WebKit's default minimum timer limit lower -
something like 3ms-5ms. I don't know what we would do to verify that
this is "safe enough" or who would do the work. Maybe Hyatt?
3) Determine whether other browser vendors would be willing to change
the minimum timeout for setTimeout and setInterval (which would not
eliminate the risk with legacy content but would reduce its severity
over time). If others agree this is worth pursuing, I can at least ask
on the HTML WG mailing list.
Thoughts?
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
