[webkit-dev] setTimeout as browser speed throttle

[Darin Fisher]

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
>
>  In short, our architecture makes me more willing to take risks with
>> setTimeout clamping than I would be otherwise.  This is a good thing I think
>> because we have the opportunity to test this out and get more data without
>> risking as much.
>>
>
> I guess I don't expect it to make a huge difference but if you would like
> to test a value higher than 1ms but less than 10ms in live code I'd
> certainly love to hear the results.
>

When we have that data, we'll share it.  I'm not sure when that will happen.



>  I think we just disagree here.  In my opinion since setTimeout clamping is
>> so varied across browsers and even varies in Firefox depending on whether or
>> not a flash animation is going, the expectation of consistent clamping has
>> to be low.  Or at least it has to be the case that it doesn't matter much if
>> different browsers have different clamping values in practice.  So I think
>> there is room to do interesting things related to different power management
>> states.  Anyways, I'm just telling you what we are considering doing.
>>
>
> I'm not really talking about developer expectation here so much as the
> possibility that, if indeed a lower clamp is a performance improvement for
> real sites, then said sites would noticeably slow down the moment you
> unplug. As a user I would find that surprising and weird.
>


My laptop slows down considerably when I unplug it because of power saving
settings.  I don't find that too unusual.




>  (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.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/a20e38ab/attachment.html