GitLab

The feature flag that I added to control whether the Windows timer
interval on DC power should be 4 ms or 8 ms had a race condition in that
we might query the feature flag before the feature-flag system was
configured. This change fixes that by adding the
ReadMinTimerIntervalLowResMs function which is called after the feature
system is initialized.

While working on this I realized that ActivateHighResolutionTimer and
EnableHighResolutionTimer were extremely subtle so I simplified them.
When calling timeBeginPeriod you *must* eventually call timeEndPeriod to
undo your request, and you must call it with exactly the same value.
With the raised timer frequency now having three possible values (1, 4,
or 8 ms) the logic was getting far too messy so I now do the simpler
task of just recording the value passed to timeBeginPeriod and using it
in timeEndPeriod. This is more obviously correct.

The new rule is that timeBeginPeriod and timeEndPeriod should always be
called with g_last_interval_requested as the parameter.

I also tidied up and expanded on some comments - I always get confused
by the purpose and semantics of ActivateHighResolutionTimer and
EnableHighResolutionTimer.

I tested with --disable-highres-timer, with and without
--enable-features=SlowDCTimerInterruptsWin, using
trace_timer_intervals.bat to confirm that all Chrome processes were
lower the timer interrupt setting to 4 ms or 8 ms as requested.

Bug: 1033108, 927165
Change-Id: I69b9253b456d7e3273ea1823a61c20926b0a4510
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1965846Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#726561}