Bug 153042
| Summary: | Windows system timer resolution needlessly cranked up when nextFireTime is in the past | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | John N. Lehner <jnlehner> |
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | achristensen, bfulgham, peavo |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
John N. Lehner
In http://trac.webkit.org/browser/trunk/Source/WebCore/platform/win/MainThreadSharedTimerWin.cpp
if MainThreadSharedTimer::setFireInterval() is called with an interval of 0, as will happen when ThreadTimers::updateSharedTimer() executes
m_sharedTimer->setFireInterval(std::max(nextFireTime - currentMonotonicTime, 0.0));
with nextFireTime in the past, then the following executes:
138 if (Settings::shouldUseHighResolutionTimers()) {
139 if (interval < highResolutionThresholdMsec) {
140 if (!highResTimerActive) {
141 highResTimerActive = true;
142 timeBeginPeriod(timerResolution);
143 }
highResolutionThresholdMsec is 16, so 0 < 16 and we call timeBeginPeriod(1) which stays in effect ~1/3 of a second. This increases power consumption needlessly.
We should only increase the system timer resolution if we're going to actually proceed to the CreateTimerQueueTimer() call; if we're going to PostMessage() immediately no resolution increase is necessary.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Brent Fulgham
Nice catch! We'll try to allocate some time to this soon.