|timeBeginPeriod(1) continues to be used all the time|
|Reported by albertod...@gmail.com, Jun 14 2010||Back to list|
Chrome Version : 6.0.428.0 (49140) URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 4: ??? Firefox 3.x: OK IE 7: OK IE 8: OK What steps will reproduce the problem? 1. Open Google Chrome 2. See the number of interrupts/second rise fivefold What is the expected result? Not rising so much. What happens instead? It rises permanently. Please provide any additional information below. Attach a screenshot if possible. Fist off, while bug 2039 is masked as fixed, it's currently broken both on Chromium nightly snapshots and in stable current releases, on both XP and Windows 7. I haven't tested whether it actually worked at any point of time, but it's been broken for months now. I tested both starting and then switching to battery power, and starting while on battery power. On both cases Chromium held the timer resolution at 1ms. There are several ways to check this. Using Process Explorer, you can look for the number of interrupts/second ("Interrupts" process, "CSwitch Delta" column). You can also use a tool like the one found here: http://www.lucashale.com/timerresolution/ which displays the current resolution exactly (it doesn't live-update so you have to restart it to check for changes). That said, even if 2039 was fixed, unconditionally raising the resolution is wrong and unnecessary in most cases, even when in AC power. In bug 888 comment 4, firstname.lastname@example.org says "Flash, Quicktime, and Windows Media all set timeBeginPeriod(1), which changes the clock resolution to 1ms." For Quicktime and WM this makes sense, since they're media players. However, note that in Windows 7 Windows Media won't increase the resolution until you're actually playing a video file. Audio files get 10ms (10 times less interrupts). Finally, Flash fixed this issue in their 10.1 release. For hidden Flash objects, the player won't increase the timer resolution at all (unless they're actively playing audio/video). For low framerate visible players it tries to increase the resolution as little as possible (10ms or 5ms). In some cases (such as currently playing video or visible high framerate animations) it does go up to 1ms, but it's far from permanent. So it'd be really nice if Chrome could play a bit nicer there; Chrome is the only browser I'm aware of that does this, the rest get by fine. I don't doubt some poorly designed webpages would run more slowly, but this can be handled better (for example if no visible pages have pending setTimeout()s or active setInterval()s with low values, decrease the resolution). If that's too hard, consider raising it to 5ms or so - setTimeout is already limited to 4ms and setInterval to 10 IIRC, so they wouldn't get affected a lot, and 5 is five times better than 1. Changing the "startup" value wouldn't affect HTML5 <video> and <audio> playback, since the timer resolution gets set to 1ms elsewhere while they're playing. If you want to test what would happen without recompiling, you can search for the hex string 807C2404006A01 in chrome.dll and change it 807C2404006A40 (the last byte is the value passed to timeBeginPeriod(), values larger than 15 do nothing). I don't notice any problems other than the tab animations run a little slower (but that's another bug - animation speed shouldn't depend on timer fire rate, and a 16ms resolution already allows > 60fps).
Jun 28 2010,
Jun 29 2010,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=51102 ------------------------------------------------------------------------ r51102 | email@example.com | 2010-06-28 21:58:15 -0700 (Mon, 28 Jun 2010) | 25 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/app/hi_res_timer_manager_win.cc?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop.cc?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop.h?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop_unittest.cc?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/base/test/test_suite.h?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/base/time.h?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/base/time_win.cc?r1=51102&r2=51101 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/test/net/fake_external_tab.cc?r1=51102&r2=51101 Change chrome from statically enabling high resolution timers on windows to enabling them dynamically - only when the application really needs them. I am working on some test cases for this, and will add them. But wanted to send out the concept for review. In this implementation, I modify the message loop to detect when the application has requested high resolution timers. Note that there are multiple MessageLoops active in a single process. After a period of time, we simply shut it off again. We could have set a timer or kept a count of active timers, or any number of more complex algorithms. But I think this algorithm is very simple and good enough. If an application continues needing high resolution timers for more than 1s, we'll turn the high-resolution timers back on again. One last change - since we've implemented the clamp at 4ms, there isn't a lot of point to our use of 1ms for timeBeginPeriod. I've modified that to 2 (which is half of 4ms, our target minimal interval). BUG= 46531 TEST=MessageLoop.HighResolutionTimers Review URL: http://codereview.chromium.org/2822035 ------------------------------------------------------------------------
Sep 15 2010,
Oct 12 2012,
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Mar 11 2013,
|► Sign in to add a comment|