On Sep 30, 2008, at 3:41 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson <[EMAIL PROTECTED]>
wrote:
If we add a new well specified API that all browser vendors agree
on, everybody wins.
No; everybody who's willing and able to change wins.
Everyone else wins or loses depending on whether the new behavior is
better or worse for them. My argument is that this makes life
better for nearly all pages affected. The entire reason to change
setTimeout() is precisely _because_ not everyone will change their
web pages.
(Furthermore, I claim the number of people who will realize they
could get something better, and change their code to get it, is
lower than the number of people who will see that something is wrong
and fix it.)
negates the need to introduce new incompatibilities into the already
published web by changing setTimeout().
This still implies there is a meaningful compatibility hit to making
this change. I have not yet seen any reason to agree that is the
case (in the sense of "CPU usage is not a web compatibility
issue"). There is _already_ no compatibility here. Browsers do
completely different things, of an equivalent magnitude (6 ms) to
the suggested change of 10 ms -> 3 or 4 ms. Firefox is even
different based on whether Flash happens to be running! How can
there be compatibility problems introduced by this proposal that
don't already exist?
This is purely theoretical (as I said before, I think lowering the
clamp value is reasonable), but one could imagine JS games that have a
"reasonable" speed variance because of current browser clamps. In
other words the game remains playable because of the reasonable clamp
limits. Going from 10ms to 1ms is a gigantic boost in "frame rate"
for a naively coded game that is just using 0 timeouts. Lowering to
1ms could cause the game to become so fast that it would no longer be
playable.
As someone said before, the difference between 10ms and 15ms is not a
wide variance compared to 10ms and 1ms.
dave
([EMAIL PROTECTED])
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
