Closed Bug 603587 Opened 14 years ago Closed 7 years ago

Timer Resolution is changed when playing flash, but not set back when tab closed

Categories

(Core Graveyard :: Plug-ins, defect)

All
Windows
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: b1356088, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

Firefox changes the timer resolution when you open a website containing flash, to 1ms. 
First: Is it really necessary to change the resolution so deep? Should 5ms not be sufficient?
Second: Problem is, when Tabs with Flash are closed, timer resolution stays at 1ms. You have to restart Firefox to get it back to 15.6ms. 

Timer resolution of 1ms is bad, it reduces performance, because there are more context switches, in addition, there is more power consumption.
Microsoft states that this changed timer resolution can reduce battery life of up to 25 %. See http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx

Reproducible: Always

Steps to Reproduce:
1. Download clockres vom http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx It should give you a timer resolution of 15,6 ms.
2. Now open Firefox, clockres should give you still 15,6 ms. (if not, please select about:blank as startpage, thats when your startpage contains flash)
3. Now open a video on youtube (or another website using flash). Now execute clockres again. Timer resolution has gone down to 1ms. 
4. Close the Tab with youtube, execute clockres. Clockres still tells you 1ms of TimerResolution. 
5. Close Firefox, Timer Resolution is back to 15,6ms


Actual Results:  
Timer Resolution stays at 1 ms when closing the tab(s) containing flash.

Expected Results:  
Timerresolution should be set to 15.6 ms as soon as the tab is closed.
Timer resolution could also be set to 15.6 ms as soon the tab with flash isn't shown anymore (because another tab has focus).

Requests to the changed timer resolution can be tracked with "powercfg -energy" (please excecute as admin). There you see, it is firefox.exe which requests the high timer resolution of 1ms.

I'd like an option that firefox never changes timer resolution. Even with 15.6 ms there is still good audio and video playback possible.
Version: unspecified → 3.6 Branch
Even Microsoft now regards this as a severe problem and their new version of InternetExplorer does not longer change the timer resolution when running on battery power.
As Microsoft states this als leads to higher energy costs on a normal computer. I hope Mozilla creates an option to freeze the timer resolution so that Firefox leaves that value untouched. Go Green!
Is this still reproducible? bug 1106115.
Component: General → Untriaged
Flags: needinfo?(b1356088)
Product: Firefox → Core
Version: 3.6 Branch → Other Branch
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
BuildID: 20160204030229

I was able to reproduce this issue exactly as described by the bug reporter. Current timer intervall goes down to 1ms and stays there until Firefox is closed.

However, i don't really know if this is a bug or planned behavior when not running on battery as described in ipc/chromium/src/base/time_win.cc:

// The next logical choice is timeGetTime().  timeGetTime has a precision of
// 1ms, but only if you call APIs (timeBeginPeriod()) which affect all other
// applications on the system.  By default, precision is only 15.5ms.
// Unfortunately, we don't want to call timeBeginPeriod because we don't
// want to affect other applications.  Further, on mobile platforms, use of
// faster multimedia timers can hurt battery life.  See the intel
// article about this here:
// http://softwarecommunity.intel.com/articles/eng/1086.htm
//
// To work around all this, we're going to generally use timeGetTime().  We
// will only increase the system-wide timer if we're not running on battery
// power.

But there seems to be some independent use of TimeBeginPeriod(1) in other media-related code and i don't know if battery use is respected there?

Can someone provide info on that or try to reproduce with a laptop on battery power?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(b1356088)
Version: Other Branch → 1.9.2 Branch
Hardware: x86 → All
Version: 1.9.2 Branch → Trunk
Whiteboard: Bug
Whiteboard: Bug
I could reproduce this bug on my laptop with power supply attached in Win 10 (latest Nightly), however if I use my laptop in battery mode the clock resolution doesn't change to 1ms.
So this bug seems not to affect laptops on battery power which is a good message.
OS: Windows 7 → Windows
Component: Untriaged → Plug-ins
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.