Submit News Alternative Tip Form

Chrome Beta Brings Fixes for Windows Battery Drain Bug


“Om nom, battery!”, said Chrome

Rewind back to the middle of July and amid the balmy British summer Google Chrome came under heat from Windows users for consuming as much as 25% more battery than other browsers.

The cause of the battery drain was levelled at a technical-sounding internal setting known as the “System Clock Tick Rate”, a task responsible for waking the processor at a given interval to ensure the browser has enough power to handle what it’s doing.

Internet Explorer and Mozilla Firefox use a default SCT rate that will call on the CPU around 64 times per second under typical usage. Chrome, however, was a little more needy. Its SCT rate was set to wake the CPU as much as 1000 time per second — even when left idle in the background!

Temper the outrage. Fixes for the issue have arrived in the latest batch of Chrome beta builds.

Chrome Beta

Fast forward a few months and fixes for the rogue “timer issue” are now beginning to filter down to the browser’s Beta channel users, fixes that Chromium developers will be hoping address the rogue battery issue on Windows once and for all.

Among several commits by Chromium’s Carlos Pizano aimed at addressing the ‘high resolution timer’ issue is this one:

“Currently while on battery we disable calls to timeBeginPeriod which make the windows timers have 15ms resolution. This change makes it so when EnableHighResolutionTimer(true) which is on AC power the timer is 1ms and EnableHighResolutionTimer(false) is 4ms.”

This change alone Pizano says “should provide significant power savings while meeting some timer resolution requirements needed by the GPU compositor.”

Has Tick Rate Been Fixed?

Do these recent commits make a difference to power consumption?

This being Beta — ergo, there are a multitude of other changes, bugs, etc. at play — it’s too early to say one way or another. But performing a totally unscientific, “leave it open and see” test, I can say that battery life on my Windows 8.1 tablet did not drop as quickly as it has in the past. Obvious caveat being this might be down to a multitude of reasons besides Chrome.

The real impact of these fixes, not to mention any yet to arrive, is only likely to become apparent when the feature rolls into the Stable Channel releases. Then, with more eyes, hands and technical aptitude examining the changes will we really be able to know.

You can download Chrome Beta for Windows from Google.

h/t Wade Menard

  • SomeUser1

    I like that the bug is fixed, but the elephant is still in the room. How come firefox and IE never had this issue? How come Chrome is still waking up the CPU with the same frequency if the PC is on AC power? Why does the Chrome renderer needs so much power, while firefox performing as good as chrome is able to wake the CPU with a much reduced frequency? What they did is not a fix. They just forced the browser not to call the CPU so frequent when on battery. This is not a fix, it’s a workaround. A fix would be to optimize the offending code that needs so much CPU power.

    • Will Saunders

      I think the reason Chrome was waking the CPU so frequently was mostly to enable those ‘faster than’ ads, where they show how quickly Chrome responds compared to some other thing. If Chrome is waking the CPU 1000 times a second, it can respond in 1/1000th of a second whereas if Firefox is waking the CPU 64 times every second, it can only respond in 1/64th of a second. I agree it’s an unnecessary compromise though because the speed advantage gained over other browsers only exists while the other browsers are operating at a lower tick rate, and they all increase it as soon as you ask them to do anything anyway, so at best you gain a fraction of a second ( 0.014625 seconds maximum, I think) by using Chrome’s method.