[webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

HI Darin,

On Oct 3, 2008, at 1:22 PM, Darin Fisher wrote:

> On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns <robburns1 at mac.com> wrote:
> Hi Darin,
>
> On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
>
>> On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <mjs at apple.com>  
>> wrote:
>>
>> On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
>>
>>> On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <mjs at apple.com>  
>>> wrote:
>>>
>>
>>> (I don't understand your comment about not having to have it on  
>>> all the time.  Surely if a page is asking for a fast setTimeout  
>>> repeatedly, it would be on "all the time.")
>>>
>>> My understanding is that timeBeinPeriod(1) is currently on all the  
>>> time in Chrome, even when no short-delay timers are currently  
>>> pending, thus leading to constant greater power consumption. But  
>>> there is no need for it to be on when there are not fast timers  
>>> pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that  
>>> is a technically better approach than switching based on power  
>>> management state. Feedback welcome, though, and perhaps you will  
>>> still come to a different conclusion.
>>>
>>> I think that is a good idea too, but it doesn't help when a fast  
>>> setInterval is active.
>>
>> That is true. With the webkit.org version of SharedTimerWin,  
>> though, you can at least close the problematic tab when you hear  
>> your fan spin up and stop suffering any power drain. It may be that  
>> running slower is a better option.
>>
>>
>> Yeah, that's the trade off.  Close the offending tab or let it run,  
>> but more slowly.
>
> Another option, would be to halt timers for all unexposed tabs  
> (i.e., tabs in windows that are not the frontmost tab). Are there  
> use-cases or sites that would break with such behavior? The reason I  
> raise this option is that the loaded page represents important state  
> to the user, but when it is buried on a window, it is probably not  
> necessary for it to be actively responding to timer callbacks.  
> Closing the tab saves battery life, but burying the tab behind  
> another tab would be preferable for the user (a mobile user that may  
> not be online when that important state represented by the page  
> loaded in the tab is sought again).
>
> Take care,
> Rob
>
>
> It's a good question.  I suspect though that it could break sites.   
> Imagine a calendar application that wishes to periodically wake up  
> to see if it should put up an alert to notify you of an upcoming  
> event.  Such a feature probably requires the ability to run a timer.

Yes, understood. But this example also requires javascript enabled. If  
a user disables javascript this web app will not work either. I'm  
suggesting WebKit could allow more finegrained control by allowing  
javascript enabled, but timers disabled.

Also this example illustrates how an author of such a calendar web app  
may use setTimeout as a polling device rather than using an event- 
based approach where the application simply sets event timers for  
those alerts. By allowing greater control over disabling setTimeout,  
the authoring community will be forced to learn about better  
approaches to authoring such a web app. Obviously this stuff won't  
happen tomorrow, but we have to take a long view of it from time to  
time and think about what we can do to get there.

Take care,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081003/06720fc5/attachment.html