[webkit-dev] High Resolution Timer API proposal(s)

[Rob Burns]

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.