1352074 - Firefox fixes Windows system timer resolution to 1 ms on certain web-pages

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Timur Born]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323105023

Steps to reproduce:

- run a monitoring app that lists the current Windows timer resolution (15.625 default)

- start Firefox in Safe Mode (no addons) on a tab with a web-site that does not provoke the issue.
- switch to a tab with a web-site that does provoke the issue.
- stay idle for some time, switch back to the other tab, close all tabs.
- restart Firefox on the tab that does not provoke the issue.
- compare with Chrome v57 on the very same web-sites.

Web-sites that cause Firefox to switch to 1 ms system timer resolution without switching back:

https://www.gearslutz.com/board/music-computers/

http://www.pcworld.com/article/3178406/components-processors/how-to-use-ryzen-master-amds-powerful-new-cpu-overclocking-tool.html

http://eatsmarter.de/ernaehrung/ernaehrungsarten/eiweisshaltige-lebensmittel

http://www.overclock.net/t/1624603/rog-crosshair-vi-overclocking-thread/5700_50#post_25969380

PS: some addons also seem to cause Firefox to set timer resolution to 1 ms.


Actual results:

Windows system timer resolution is fixed at 1 ms once certain elements on some web-sites are displayed. It does not switch back to 15.625 ms after any reasonable amount of time even when the tabs/web-sites are closed.


Expected results:

Windows system timer resolution should be at its default 15.625 ms most of the time. When certain web-site elements (or addons) need a higher time resolution for a short period of time the timer should be reset back to lower resolution as soon as possible.

Chrome v57 and Microsoft browsers demonstrate that the same web-sites (elements) can work with lower timer resolution and thus lower power/battery drain.

Comment 1

[Loic]

Timothy, are you still aware of this code area in Firefox?

Comment 2

[Timothy Nikkel (:tnikkel)]

If a website uses requestAnimateFrame we use high precision timers, but it should go back to normal after the page is gone for a while. That sounds like a bug.

Mason, do we still need to enable high precision timers if we have raf callbacks on Windows?

Comment 3

[Timothy Nikkel (:tnikkel)]

(In reply to Timothy Nikkel (:tnikkel) from comment #2)
> If a website uses requestAnimateFrame we use high precision timers, but it
> should go back to normal after the page is gone for a while. That sounds
> like a bug.

I know this worked for at least one testcase at one time because I remember fixing such a bug in the past.

Comment 4

[Mason Chang [Inactive] [:mchang]]

It really depends which timer the page is on. Most pages should be getting the vsync timestamp for rAF if it's an active page. Some elements / pages may be going to an inactive timer, which was done by Seth. However, the inactive timer should be much longer than 1 ms. I'm not even sure how we're getting 1 ms timers in general? That seems quite odd. When does that happen?

Comment 5

[Mason Chang [Inactive] [:mchang]]

I found out some history of this. Pre-Silk life, we enabled high resolution timers on Windows to have more accurate rAF callbacks with software timers. However, since we're with vsync life now, rAF shouldn't fire until vsync fires, which means we probably don't need to enable these high resolution timers in general anymore. Will delete I think.

Comment 6

[Timothy Nikkel (:tnikkel)]

Talked to Mason on irc.

For reference this is the origin of this code https://hg.mozilla.org/mozilla-central/rev/513ec84b5c88

Comment 7

[Timur Born]

Do I understand that old code correctly that it takes 10 minutes for timers to reset to "normal"? I am no coder, so bear with me.

My comment didn't show up, so I write this again with more information: The Eatsmarter web-site can sometimes contain a div.video-container on its right side. When the video is started the Windows timer resolution even switches to 0.5 ms! Once the video is stopped resolution changes to 1 ms immediately.

Comment 8

[Timur Born]

(In reply to Timur Born from comment #7)

> When the video is started the Windows timer resolution even switches
> to 0.5 ms! Once the video is stopped resolution changes to 1 ms immediately.

I just noticed that the very same happens with Youtube videos. Once playback is started timer changes to 0.5, once playback is stopped it immediately switches back to 1 ms.

Comment 9

[Timothy Nikkel (:tnikkel)]

(In reply to Timur Born from comment #7)
> Do I understand that old code correctly that it takes 10 minutes for timers
> to reset to "normal"? I am no coder, so bear with me.

There are three different types of timers in the refresh drivers:
1) visible and highprecision (60fps, high precision timers)
2) visible (60fps)
3) background (<=1fps)

1) is when you are seeing the 1ms timer resolution.

The code I linked stops doing highprecision after 90 seconds. timeBeginPeriod/timeEndPeriod is what changes the timer resolution.

The ten minutes you saw was probably for background tabs

> My comment didn't show up, so I write this again with more information: The
> Eatsmarter web-site can sometimes contain a div.video-container on its right
> side. When the video is started the Windows timer resolution even switches
> to 0.5 ms! Once the video is stopped resolution changes to 1 ms immediately.

The media stack (what plays html5 vidoes) also uses timeBeginPeriod/timeEndPeriod

https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaDecoderStateMachine.cpp

Comment 10

[Timur Born]

Thanks for the explanation.

So why does HTML5 video need 0.5 ms timer resolution? Why does it need any high resolution at all, since it's only playing back some mostly non-interactive content at 60 fps (if at all)?

Comment 11

[Timothy Nikkel (:tnikkel)]

Since I was in the mood to remove code I pushed the removal of this code to try server to see if anything showed up

https://treeherder.mozilla.org/#/jobs?repo=try&revision=32b5d3ddd69cf3335d5eedf6932e877c30b99e7f

Comment 12

[Mason Chang [Inactive] [:mchang]]

(In reply to Timothy Nikkel (:tnikkel) from comment #11)
> Since I was in the mood to remove code I pushed the removal of this code to
> try server to see if anything showed up
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=32b5d3ddd69cf3335d5eedf6932e877c30b99e7f

Our infra didn't seem to like that push. Here's another one - https://treeherder.mozilla.org/#/jobs?repo=try&revision=35188dd44cb6e9bad9a0d41ce9051dc93ba42465

Comment 13

[Mason Chang [Inactive] [:mchang]]

I talked with Shu from JS and Blake from DOM. They think it should be ok to stop using these timers, they didn't expect that they needed them.

Comment 14

[Timothy Nikkel (:tnikkel)]

Attachment: remove high precision timers

Comment 15

[Timothy Nikkel (:tnikkel)]

Timur, if you want to try a build with this change you can download a 64bit or 32bit build from these links

https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-35188dd44cb6e9bad9a0d41ce9051dc93ba42465/try-win64/

https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-35188dd44cb6e9bad9a0d41ce9051dc93ba42465/try-win32/

Or wait a day or two and try Firefox Nightly.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e4f4a089dc2d
Remove high precision timer mode from refresh driver because it is not needed with vsync based refresh drivers. r=mchang

Comment 17

[Timur Born]

(In reply to Timothy Nikkel (:tnikkel) from comment #15)
> Timur, if you want to try a build with this change you can download a 64bit
> or 32bit build from these links


Hi Timothy,

thanks for the build and links, it's well appreciated. The built doesn't play nicely with Ublock Origin, so I used Adblock Plus to block out timer resolution offending ad containers for testing (see below).

I tried the 64 bit build and it is a lot better, but not fully fixed yet.

The good:

For various elements 1 ms timer precision is only used during loading of the page/elements and then set back to 15 ms quickly.

The bad:

There are still some container elements (mostly ads it seems) that fix the timer resolution to 1 ms. These neither seem to be animations (not in inspector at least) or video. When a tab with such an element is closed it seems to take exactly 10 seconds before timer resolution is reset to 15 ms.

In Chrome the behavior is considerably different in that the timer is reset to 15 ms as soon as a tab with these elements is sent to the background (aka switching to another tab). It even so happens that when you scroll away from the "offending" element the timer is reset to 15 ms. In these two cases Chrome only seems to "refresh" the timer every few seconds (short dip to 1 ms and back up to 15 ms).

The following two web-sites currently demonstrate the issue (reload several times until a "offending" ad container is displayed):

http://www.bento.de/art/marvel-entschuldigt-schlechte-comic-verkaeufe-wegen-der-frauen-1283892/#refsponi
http://eatsmarter.de/

The ugly:

Playing HTML5 video (Youtube) seems to lower the timer to 0.5 ms in all browsers I tested. During pause it changes to 1 ms. Maybe Firefox could improve on that situation by at least resetting the timer to 15 ms when the corresponding tab (or whole browser) is in the background?

On a side note: I can literally hear timer changes, because my Asus Crosshair Hero VI has such a badly buzzing VRM section that kind of "rings the alarm" when the CPU voltages finally drop to idle level (timer at 15 ms). ;)

Comment 18

[Timothy Nikkel (:tnikkel)]

Okay, thanks for testing. There are other callsites of timeBeginPeriod in the tree besides refresh driver and the media stack that I'm not familiar with.

Since we landed a significant change in this bug already we'll close this bug (things get confusing if we leave bugs open where patches have landed) so let's get a followup bug on file to look into reducing 1ms timer usage even further.

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e4f4a089dc2d

Comment 20

[Timothy Nikkel (:tnikkel)]

Timur, did you want to file a followup bug?

Comment 21

[Timur Born]

(In reply to Timothy Nikkel (:tnikkel) from comment #20)
> Timur, did you want to file a followup bug?

Sorry, I didn't get a e-mail for your yesterday's post. If you think that the ad container thing can be improved then yes, filing a follow up bug makes sense. That 10s to reset the timer resolution should help find the relevant code. ;)

I lack experience with your system here. Do I start a whole new bug report or do you create a follow up out of this one here?