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