On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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.

Are you planning to test a specific alternate interval?

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.

Mine doesn't. Instead it slews the CPU clockspeed based on workload and shuts down components (including the CPU) whenver possible. Get a Mac. :-) In all seriousness, I see your point for Windows machines. User expectations for the unplugged state may be lower.

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

Cheers,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to