Hi Geoff, On Oct 3, 2008, at 9:04 PM, Geoffrey Garen wrote:
>> Again, I'm wondering how many legitimate uses are there for short >> timeouts in background tabs/windows. > > In a background window: > animation > video For animation and video, is it necessary even in a completely obscured view? > audio I only meant to discuss javascript here. Are authors spinning audio using javascript setTimeout (I ask naïvely)? > work queues for database or other background processing I think this is another example where event listeners or another approach entirely would be more legitimate than using timers. Are you talking about using setTimout to repeatedly poll to find out if a worker is finished? If so, this is definitely not the type of use we should facilitate long-term for script timers. Again, exploring these questions may lead us to a need to define other events that can trigger scripts to run (rather than reliance on polling). > something interesting the web hasn't invented yet Given the need to reign in the abuses I don't find this too compelling. We wouldn't be preventing innovations, just restricting those innovations to run in unburied web pages. > To give you some context, Safari used to throttle plug-in timers for > background windows. The result was that users would see randomly > choppy content. I'm more referring to pages that are completely buried and obscured so pages with no need not run at all and users would have no way to know they are running choppy. > In a background tab: > audio Again is this being done with javascript? Anyway, I don't think it is much to ask of users that they keep tabs unburied to enable listening to the embedded audio (or otherwise for browsers to provide an interface to re-enable audio within those buried tabs). So authors and users do not already have any ingrained preconceptions that audio must play even if a tab is buried (and so need to tailor APIs for authors to micro-manage this). > work queues for database or other background processing > something interesting the web hasn't invented yet See above. > Also note that protections for background windows and tabs wouldn't > solve the majority of the problem we've seen in the wild, which is > the *foreground* window going crazy in a single-tabbed browsing > session. I feel completely the opposite about this. If a foreground window is going crazy, that's a problem but a visible problem that even a novice user may know how to correct (if it even needs correcting). However, finding one or a dozen background tabs (amidst tens or hundreds) where those tabs contain needlessly running timers (in both javascript and elsewhere) is a huge power drain and one whose impacts are difficult to access. For mobile users the problem is more obvious, but even for desktops, how much wasted energy goes into these cycles when repeated across millions (billions?) of processors world-wide (and then the air-conditioning that also goes into compensating for that needless heat generation)[1]? Take care, Rob [1]: A bit off-topic: say a processor pegged at 20w churns away at these wasteful web app cycles for 2 hours each day driving the processor from an average of 10% power consumption to 99% power consumption. That's 17.8 power dissipation dedicated just to the needless cycles or 35.6 w-h energy consumption per day. For one billion computers that's 17.8 thousand MW or 35.6 thousand MW-h per day or 9256 thousand MW-h per work year. Avoiding something like 17.8 thousand wasted MW power dissipation (and 9256 thousand MW-hours of energy) eliminates the need for dozens of nuclear / coal power reactors worldwide (or even dirtier peaker power plants). Considering a 1.341 pounds of CO2 per kilowatt-hour (the 1999 estimated rate so over-optimistic for world-wide electricity production) that's 12,412 pounds per year. At 10¢ a kw-h that's $925 million per year in world- wide electricity expenses. And that's without calculating compensating cooling power consumption, both internal and external to the computing device. There's a lot of power (and potential power wasted) in the hands of browser developers. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
