On Fri, Nov 19, 2010 at 11:32 AM, Gregg Tavares (wrk) <gman@google.com>wrote: > I totally see that some bad code could be error prone if we don't guarantee > the callback is eventually fired. On the other hand, guaranteeing it gets > fired even if it's offscreen seems to have all the other repercussions > (excess cpu usage, excess memory paging), those both could lead to a bad > browsing experience. It seems like guaranteeing animationFrame callbacks > get called even when offscreen is helping bad programmers (their incorrect > code works) where as never calling them when offscreen is helping users > (their browser is more likely to be responsive). Is there some way to solve > both issues? > Helping bad programmers is not a bad thing. Helping bad programmers helps users, because they are less likely to encounter bugs. Given that millions of Web applications use constant setTimeouts today, and will continue to do so no matter what we do, I think rather than trying to make requestAnimationFrame more efficient at the expense of making it error-prone, it would be better for implementors to come up with more general solutions to the "busy background tab" problem. For example, a browser could force the HTML5 event loop for a background tab to sleep for arbitrary periods of time. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Received on Friday, 19 November 2010 01:59:29 UTC