Peter Kasting | 1 Oct 02:13 2008

Re: setTimeout as browser speed throttle

On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:
Can you cite some of the existing sites that would benefit? That would help others confirm the benefit and also estimate likelihood of said sites adopting a new better API for greater benefit.

Sure.   http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser describes how to make apps doing long-running calculations responsive by breaking them into small chunks and using setTimeout(..., 0).  This is precisely the type of pattern we hope to speed up.  On the sample page at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html , Chromium runs the test in about 1 sec, compared to ~15.6 sec in Safari 3.1.  Even the "optimized" version at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html is still faster.

An obvious example is John Resig's timer perf bench at http://ejohn.org/apps/timers/ , which I'm sure you're familiar with.  This loads up about 15x faster since it uses setTimeout(..., 0).  One can argue about the relative worth of this benchmark, of course, but then I seem to remember from our last lunch that the WebKit team generally had the philosophy of "speed up the benchmark regardless, and complain about the validity of it in parallel if necessary" :)

These two are some of the most obvious cases, where loading the page takes dramatically less time, but there are more subtle wins.  For example, Chromium should save about 9 ms on http://www.benya.com/code/jsbenchmarks/table-rendering-benchmarks.html due to the uncapping.

A sample page which is theoretically, but seemingly not practically, helped by this is http://hassing.org/projects/asteroids/ .  At least on my machine, the CPU load is low enough that the difference between Safari's 100 FPS cap and Chromium's 1000 FPS cap is unnoticeable.  I suppose that on a slow/heavily loaded machine things might be different; not sure.

Similarly, http://cometdaily.com/2008/08/11/robust-network-code-with-windowsettimeout/ describes a pattern that will save a bit of time on some callbacks, but I don't actually have a testcase where that sample code is used.

These few examples are what I had off the top of my head.  If you'd like, we can do a more exhaustive search for affected pages and get back to you with the results.  (The guy who has that data isn't around ATM.)

PK
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Mike Belshe | 1 Oct 02:15 2008

Re: setTimeout as browser speed throttle

On Tue, Sep 30, 2008 at 3:45 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:

On Sep 30, 2008, at 3:06 PM, Mike Belshe wrote:

Subjective note:

I'm much more worried about sites spinning the CPU accidentally (e.g. they used setTimeout(0) somewhere by accident) than I am about frame rates on games.  Using the clock as your frame rate is super buggy, and sites need to know better.  It won't work now and it won't work going forward.

If you recall - there used to be a "TURBO" button on PCs as they made the switch from 8MHz to 12MHz to address this issue.  Turbo buttons don't exist anymore.

Anyway, this is a personal preference; I have little sympathy on the game front - but more sympathy on the accidental CPU front.

Our attitude towards Web compatibility generally is that if a Web site works reasonably in other browsers but does not work in Safari, then it is presumptively our bug. That is what users will assume, and lectures about how foolish the site developer was tend to have little effect. Thus, sympathy or lack thereof for particular use cases does not enter into the picture. We should not be making these kinds of decisions based on our own personal opinions of the coding quality of the site.

If you follow this to the logical conclusion, then WebKit should use a 15.6ms timer. :-)

My point is that applications which are hard coded to work with a particular minimum timer value are broken already today across browsers (some are 10, some are 15, and these are significantly different).  Such applications were probably built and tested on a limited set of browsers, but it does not matter why they are this way.  Given that these apps already behave differently in existing browsers, I'm much less concerned about this issue than the CPU issue.

Mike
 


Regards,
Maciej


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Maciej Stachowiak | 1 Oct 02:31 2008
Picon

Re: setTimeout as browser speed throttle


On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:

On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:
Can you cite some of the existing sites that would benefit? That would help others confirm the benefit and also estimate likelihood of said sites adopting a new better API for greater benefit.

Sure.   http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser describes how to make apps doing long-running calculations responsive by breaking them into small chunks and using setTimeout(..., 0).  This is precisely the type of pattern we hope to speed up.  On the sample page at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html , Chromium runs the test in about 1 sec, compared to ~15.6 sec in Safari 3.1.  Even the "optimized" version at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html is still faster.

An obvious example is John Resig's timer perf bench at http://ejohn.org/apps/timers/ , which I'm sure you're familiar with.  This loads up about 15x faster since it uses setTimeout(..., 0).  One can argue about the relative worth of this benchmark, of course, but then I seem to remember from our last lunch that the WebKit team generally had the philosophy of "speed up the benchmark regardless, and complain about the validity of it in parallel if necessary" :)

These two are some of the most obvious cases, where loading the page takes dramatically less time, but there are more subtle wins.  For example, Chromium should save about 9 ms on http://www.benya.com/code/jsbenchmarks/table-rendering-benchmarks.html due to the uncapping.

A sample page which is theoretically, but seemingly not practically, helped by this is http://hassing.org/projects/asteroids/ .  At least on my machine, the CPU load is low enough that the difference between Safari's 100 FPS cap and Chromium's 1000 FPS cap is unnoticeable.  I suppose that on a slow/heavily loaded machine things might be different; not sure.

Similarly, http://cometdaily.com/2008/08/11/robust-network-code-with-windowsettimeout/ describes a pattern that will save a bit of time on some callbacks, but I don't actually have a testcase where that sample code is used.

These few examples are what I had off the top of my head.  If you'd like, we can do a more exhaustive search for affected pages and get back to you with the results.  (The guy who has that data isn't around ATM.)

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? That is what you cited that as the justification for changing the existing setTimeout / setInterval APIs, rather than relying solely on new API.

Regards,
Maciej





_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Maciej Stachowiak | 1 Oct 02:35 2008
Picon

Re: setTimeout as browser speed throttle


On Sep 30, 2008, at 5:15 PM, Mike Belshe wrote:

On Tue, Sep 30, 2008 at 3:45 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:

On Sep 30, 2008, at 3:06 PM, Mike Belshe wrote:

Subjective note:

I'm much more worried about sites spinning the CPU accidentally (e.g. they used setTimeout(0) somewhere by accident) than I am about frame rates on games.  Using the clock as your frame rate is super buggy, and sites need to know better.  It won't work now and it won't work going forward.

If you recall - there used to be a "TURBO" button on PCs as they made the switch from 8MHz to 12MHz to address this issue.  Turbo buttons don't exist anymore.

Anyway, this is a personal preference; I have little sympathy on the game front - but more sympathy on the accidental CPU front.

Our attitude towards Web compatibility generally is that if a Web site works reasonably in other browsers but does not work in Safari, then it is presumptively our bug. That is what users will assume, and lectures about how foolish the site developer was tend to have little effect. Thus, sympathy or lack thereof for particular use cases does not enter into the picture. We should not be making these kinds of decisions based on our own personal opinions of the coding quality of the site.

If you follow this to the logical conclusion, then WebKit should use a 15.6ms timer. :-)

My point is that applications which are hard coded to work with a particular minimum timer value are broken already today across browsers (some are 10, some are 15, and these are significantly different).  Such applications were probably built and tested on a limited set of browsers, but it does not matter why they are this way.  Given that these apps already behave differently in existing browsers, I'm much less concerned about this issue than the CPU issue.

Degree of difference matters too, not just whether there is one. For example, a browser using a different antialiasing algorithm for text would be much more acceptable than a browser that renders black text as bright yellow, event though both in theory could make a page look different than intended.

In practice, a timer value of 10ms instead of 15.6ms does not appear to be a problem, we have historic evidence that 0ms minimum is a problem, scattered evidence that 1ms may be a problem, and no clear information on values in between such as 3ms, 5ms or 7ms.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Oliver Hunt | 1 Oct 02:35 2008
Picon

Re: setTimeout as browser speed throttle


On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:

On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:
Can you cite some of the existing sites that would benefit? That would help others confirm the benefit and also estimate likelihood of said sites adopting a new better API for greater benefit.

Sure.   http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser describes how to make apps doing long-running calculations responsive by breaking them into small chunks and using setTimeout(..., 0).  This is precisely the type of pattern we hope to speed up.  On the sample page at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html , Chromium runs the test in about 1 sec, compared to ~15.6 sec in Safari 3.1.  Even the "optimized" version at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html is still faster.

Um, if you have a complex function that you break up into interval that are too short it's going to cause poor performance -- it's just bad code simply put, and helping badly written code is not something that makes much sense (to me at least).  Alternatively if you look at http://nerget.com/rayjs3/rayjs.html you'll see it varies the amount of computation it does in each pass based on an educated guess as to how much work it can do in a reasonable amount of time, rather than just taking the most conservative approach possible and allowing the timeout delay to be larger than the computation time.


An obvious example is John Resig's timer perf bench at http://ejohn.org/apps/timers/ , which I'm sure you're familiar with.  This loads up about 15x faster since it uses setTimeout(..., 0).  One can argue about the relative worth of this benchmark, of course, but then I seem to remember from our last lunch that the WebKit team generally had the philosophy of "speed up the benchmark regardless, and complain about the validity of it in parallel if necessary" :)

The purpose of John's tests was to compare reliability and stability of each browser's timer implementation -- it's not a performance benchmark in the traditional sense.

--Oliver
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Peter Kasting | 1 Oct 03:37 2008

Re: setTimeout as browser speed throttle

On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak <mjs <at> apple.com> 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.

PK
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Maciej Stachowiak | 1 Oct 04:14 2008
Picon

Re: setTimeout as browser speed throttle


On Sep 30, 2008, at 6:37 PM, Peter Kasting wrote:

On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak <mjs <at> apple.com> 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 <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Maciej Stachowiak | 1 Oct 04:19 2008
Picon

JS binding wapper pointers: inline vs. separate hash table


One of the changes in Chrome's version of WebKit is that, instead of  
storing pointers to the JS binding object for a core object in a  
HashMap, it stores them directly in the core object. Although this  
change is not currently in the webkit.org tree, and is in the Chrome  
tree for the V8 bindings only, it's really independent of the choice  
of JS engine.

I gather some members of the Chrome team are gathering data on the  
memory cost and speed benefit, and will post that data soon. In the  
meantime, I decided to do a quick and dirty hack to do a rough estimate.

In the Chrome tree, every object inheriting from RefCounted incurs an  
extra pointer in size, but this is clearly more than necessary since  
many RefCounted objects do not have bindings. I assume this would be  
narrowed if the change were to go into webkit.org WebKit. But rather  
than find every class that may have a binding, I just counted objects  
inheriting from Node, StyleBase or NamedAttrMap on popular sites, and  
multiplied by 4. This does not count some bindable objects and does  
not account for allocator overhead, so these are lowball estimates. (I  
am also assuming that most bindable objects on these pages do not have  
a live JS binding).

GMail (load to inbox): ~135k
Slashdot main page: ~70k
Google docs start page, plus Ian Hickson's "element nesting matrix"  
spreadsheet: ~155k
daringfireball: ~16k
facebook profile page: ~140k
cnn.com: ~130k
Wikipedia article on "United States": ~135k

I did not compare to baseline memory costs for these pages (my test  
code only works in a debug build), and of course this is not going to  
be as accurate as doing real testing.

My test procedure was:

1) Apply this patch:

Index: WebCore/css/StyleBase.cpp
===================================================================
--- WebCore/css/StyleBase.cpp	(revision 37126)
+++ WebCore/css/StyleBase.cpp	(working copy)
 <at>  <at>  -26,9 +26,21  <at>  <at> 
 #include "Document.h"
 #include "Node.h"
 #include "StyleSheet.h"
+#include <wtf/RefCountedLeakCounter.h>

 namespace WebCore {

+#ifndef NDEBUG
+static WTF::RefCountedLeakCounter styleBaseCounter("WebCoreStyleBase");
+#endif
+
+StyleBase::StyleBase(StyleBase* parent)
+    : m_parent(parent)
+    , m_strictParsing(!parent || parent->useStrictParsing())
+{
+    styleBaseCounter.increment();    
+}
+
 String StyleBase::cssText() const
 {
     return "";
Index: WebCore/css/StyleBase.h
===================================================================
--- WebCore/css/StyleBase.h	(revision 37126)
+++ WebCore/css/StyleBase.h	(working copy)
 <at>  <at>  -75,11 +75,7  <at>  <at>  namespace WebCore {
         StyleSheet* stylesheet();

     protected:
-        StyleBase(StyleBase* parent)
-            : m_parent(parent)
-            , m_strictParsing(!parent || parent->useStrictParsing())
-        {
-        }
+        StyleBase(StyleBase* parent);

     private:
         StyleBase* m_parent;
Index: WebCore/dom/Element.cpp
===================================================================
--- WebCore/dom/Element.cpp	(revision 37126)
+++ WebCore/dom/Element.cpp	(working copy)
 <at>  <at>  -47,11 +47,14  <at>  <at> 
 #include "SelectionController.h"
 #include "TextIterator.h"
 #include "XMLNames.h"
+#include <wtf/RefCountedLeakCounter.h>

 namespace WebCore {

 using namespace HTMLNames;
 using namespace XMLNames;
+
+static WTF::RefCountedLeakCounter attrMapCounter("WebCoreAttrMap");

 Element::Element(const QualifiedName& tagName, Document* doc)
     : ContainerNode(doc, true)
 <at>  <at>  -513,6 +516,7  <at>  <at>  void Element::attributeChanged(Attribute

 void Element::setAttributeMap(PassRefPtr<NamedAttrMap> list)
 {
+    attrMapCounter.increment();
     document()->incDOMTreeVersion();

     // If setting the whole map changes the id attribute, we need to call updateId.
 <at>  <at>  -596,6 +600,7  <at>  <at>  bool Element::contains(const Node* node)

 void Element::createAttributeMap() const
 {
+    attrMapCounter.increment();
     namedAttrMap = NamedAttrMap::create(const_cast<Element*>(this));
 }

Index: WebCore/dom/Node.cpp
===================================================================
--- WebCore/dom/Node.cpp	(revision 37126)
+++ WebCore/dom/Node.cpp	(working copy)
 <at>  <at>  -185,9 +185,11  <at>  <at>  Node::~Node()
     HashSet<Node*>::iterator it = ignoreSet.find(this);
     if (it != ignoreSet.end())
         ignoreSet.remove(it);
+#if 0
     else
         nodeCounter.decrement();
 #endif
+#endif

     if (!hasRareData())
         ASSERT(!NodeRareData::rareDataMap().contains(this));
Index: WebKitTools/Scripts/check-for-global-initializers
===================================================================
--- WebKitTools/Scripts/check-for-global-initializers	(revision 37126)
+++ WebKitTools/Scripts/check-for-global-initializers	(working copy)
 <at>  <at>  -104,6 +104,8  <at>  <at>  for my $file (sort  <at> files) {
                 next if $shortName eq "JSCustomSQLTransactionCallback.o";
                 next if $shortName eq "JSEventListener.o";
                 next if $shortName eq "Node.o";
+                next if $shortName eq "Element.o";
+                next if $shortName eq "StyleBase.o";
                 next if $shortName eq "Page.o";
                 next if $shortName eq "Range.o";
                 next if $shortName eq "RenderObject.o";

2) Build debug.
3) Launch Safari with the built WebKit, and visit a page to be tested.
4) Quit Safari; add up the three numbers dumped and multiply by 4.

I'm looking forward to more accurate data from Chrome folks, and some  
measurements or estimates of the potential speed gain.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Justin Haygood | 1 Oct 04:32 2008

Proposed Timer API

 
It's based off Adobe's "flash.utils.Timer" API that they have in AS3. Once I get enough WK comments, I'll see about how to get it to HTML5...
 
--Justin Haygood
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Peter Kasting | 1 Oct 06:11 2008

Re: setTimeout as browser speed throttle

On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:
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.

These all seem like avenues worth pursuing.  I can try and get more data about the impact, both positive and negative, of setTimeout()/setInterval() changes; hopefully that will help make the discussions of (2) and (3) a bit more concrete.

Now if only I could get all the browser vendors to agree on their minimum GIF frame durations :D

PK
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Gmane