New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 46531 link

Starred by 13 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Sep 2010
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

timeBeginPeriod(1) continues to be used all the time

Reported by, Jun 14 2010

Issue description

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
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: 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, 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).
Status: Assigned

Comment 2 by, Jun 29 2010

The following revision refers to this bug: 

r51102 | | 2010-06-28 21:58:15 -0700 (Mon, 28 Jun 2010) | 25 lines
Changed paths:

Change chrome from statically enabling high resolution timers on windows
to enabling them dynamically - only when the application really needs

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 

Review URL:

Status: Fixed
Project Member

Comment 4 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 5 by, Mar 11 2013

Labels: -Area-Undefined

Sign in to add a comment