Excessive calls to requestAnimationFrame causes system clock to run fast

NEW
Unassigned

Status

()

--
major
6 years ago
3 years ago

People

(Reporter: neil, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
https://s.chzbgr.com/s/release_20121012.2/js-built/main-moist.js (line 168) makes repeated calls to requestAnimationFrame. This causes the refresh driver to turn high precision timers on and off repeatedly. Unfortunately as per Microsoft KB article 821893, this causes the system clock to run fast on systems using the halaacpi.dll, halmacpi.dll or the halmps.dll (but not those using the halacpi.dll or halx86.dll).

Note that bug 731974 has been backed out for now because it caused bug 797263.
That source is pretty hard to read; how does it make repeated calls to requestAnimationFrame?  To schedule additional frames in an animation?  That should be fine, we shouldn't exit high precision mode then.

We could change it so that once a page does rAF, that page keeps high precision timer mode on until it's closed.
(Reporter)

Comment 2

6 years ago
I don't actually know what the page was trying to animate. Unfortunately I've since updated my tree but as soon as I suspected KB article 82193 I put a breakpoint on timeBeginTime itself and it fired immediately. Also while I was stopped in the debugger I noticed that my clock stopped running fast.

Updated

6 years ago
Blocks: 60455
This was fixed in an update to bug 731974; the original patch was calling timeBeing/EndPeriod *way* too often (basically every frame, due to a bug).  The new patch goes one step further, and only disables high precision after an interval (currently 90s).  Hopefully this should be enough.

Note that this only affects Windows 2000, XP, or 2003 according to the kb article.  It doesn't seem to affect Win Vista(?)/7/8.
You need to log in before you can comment on or make changes to this bug.