DescriptionFix the drift in repeating timers (try #2)
Currently repeating blink timers ignore the difference between when the
timer was due to fire and when it actually did. In addition the delay
reported to chromium was rounded up to the nearest millisecond,
introducing unnecessary extra delay.
(Note seperatly DOMTimers have additional clamping).
This fairly broken behaviour has been there for a long time, and I
really hope nothing has come to depend on it!
Judging by
http://www.duckware.com/test/chrome/timeraccuracy.html this patch makes
things a lot better at least on linux. The actual delays are much
closer to the requested ones, and the run time modulo interval shows
the drift is gone.
Based on https://codereview.chromium.org/1261993006/ but without the
assert. I've added test coverage to make sure nothing bad happens
if the timer fires a little earlier than expected (which can happen
since the delay gets quantized down to milliseconds on some platforms).
BUG=328700
Committed: https://crrev.com/0d7bb8a499af076a64680f36b7b9c5b64fe334d0
Cr-Commit-Position: refs/heads/master@{#351295}
Patch Set 1 #Patch Set 2 : Fix media/blink/run_all_unittests.cc #Patch Set 3 : The unit is ms not s! #Patch Set 4 : Try to fix compile #
Total comments: 10
Patch Set 5 : Rename some variables and add a todo #
Messages
Total messages: 33 (13 generated)
|