Not without a complete recreation of the test. As explained when asked in the comments of the first article, this test includes things like manipulating the scrollbar and restarting the browser that can't be scripted from within the browser; and playing back recorded win32 keyboard/mouse events won't work in other OSes. (And even if they could, would need modification for things like close buttons on the other side of the window, etc.)
Ah, restating the browser. Well, on Linux you could use dogtail for that, then the js test kits for the rest. On Mac, as someone else said, automator is what you want. PS:I didn't see those comments on the other thread, so thanks for the info.
Thanks for the quick update and response to user feedback. It's quite interesting to see that the difference is primarily down to resolution. Perhaps a lot of the rendering is still occurring in software and thus missing out on the efficiency benefits of GPU rendering.
If that was the case, wouldn't there be a noticeable difference between 36 and 37 at 1600 x 900? I suspect it's taking advantage of hardware rendering in all cases. The issue is that Chrome 36 is always rendering at low resolution. However, I'm sure with some optimization they can close the gap a lot more.
Frankly IE11 is actually pretty darn good. Even mobile IE11 isn't bad. Go figure.
To be fair, the original article stated that the Chrome 36 results at 3200x1800 were suspect due to lack of HiDPI support. In both the results page and on the final words page.
However, I have updated the original article to link to this.
BTW I found the way to make Chrome request the normal resolution timer vs the High Res timer (accidentally discovered it doing unit test during a power outage) lol. Set the active power plan to "Power Saver" and chrome's perf with degrade ~3x just as you were hoping for :P So you may need to re-test all the browsers under that power plan too in order to get the real "battery life".
Wait, wouldn't that mean that you weren't even testing what you set out to test? If Chrome uses the regular timers on Power Saver, and you wanted to test how the fast clock affects battery life, you haven't actually tested it.
Chrome does not use regular timers on battery saver mode (or ever). See page 3 of the original article. I verified that it was indeed requesting the high priority timer as the test was running.
Also, see the second to last paragraph of the first page. It talks about this specifically.
Then explain this: I set my power plan to "Power Savings and start Chrome (Stable as you can tell by the version # in the report) AFTER setting to the power savings power plan and here: http://i.imgur.com/HlMxr3L.png to see chrome NOT requesting the higher timer WHILE running the sunspider javascript benchmark twice during the recording period AND https://mega.co.nz/#!thBUCKCT!RxVWNSEbw0b_-tCJCdrc... is the entire energy report that shows all the details of more chrome.exe processes vs just that single screen shot with 1 entry + the timer resolution to show u chrome doesn't ONLY request the high resolution timer no-matter what. BTW the Dev version of Opera based on chrome ALSO doesn't force a high resolution timer but Firefox Nightly AND Chrome Canary seems to always request the high resolution timer for me so eat your own hat anand & staff.
Given the pace of software updates, this test strikes me as a little premature. Yes, HiDPI displays are the future, but so are Chrome 41, IE 13, etc. Right now, I'd imagine the vast majority of AnandTech readers are still on traditional displays. Tests of the software/hardware combos most of use are using now would be more useful than tests of software that will be long-outdated by the time most of us are on HiDPI displays.
I would also really like to see test results from OS X. I only use Safari now because of iPhone sync and because it doesn't kill the battery if I accidentally have many tabs open with flash.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
22 Comments
Back to Article
tuxRoller - Monday, August 18, 2014 - link
Sooooooooo, no chance of performing this same task with mac and linux?r3loaded - Monday, August 18, 2014 - link
Not until they write an automated test suite for those platforms. Just be patient.tuxRoller - Monday, August 18, 2014 - link
Google "JavaScript automated testing".DanNeely - Monday, August 18, 2014 - link
Not without a complete recreation of the test. As explained when asked in the comments of the first article, this test includes things like manipulating the scrollbar and restarting the browser that can't be scripted from within the browser; and playing back recorded win32 keyboard/mouse events won't work in other OSes. (And even if they could, would need modification for things like close buttons on the other side of the window, etc.)matt321 - Monday, August 18, 2014 - link
I suggest trying Automator on the Mac side. You can create a workflow that will record what you do and then can run that workflow many times.Stephen Barrett - Monday, August 18, 2014 - link
I will check that out. Thanks!tuxRoller - Monday, August 18, 2014 - link
Ah, restating the browser. Well, on Linux you could use dogtail for that, then the js test kits for the rest. On Mac, as someone else said, automator is what you want.PS:I didn't see those comments on the other thread, so thanks for the info.
Spunjji - Monday, August 18, 2014 - link
Thanks for the quick update and response to user feedback. It's quite interesting to see that the difference is primarily down to resolution. Perhaps a lot of the rendering is still occurring in software and thus missing out on the efficiency benefits of GPU rendering.Alexvrb - Monday, August 18, 2014 - link
If that was the case, wouldn't there be a noticeable difference between 36 and 37 at 1600 x 900? I suspect it's taking advantage of hardware rendering in all cases. The issue is that Chrome 36 is always rendering at low resolution. However, I'm sure with some optimization they can close the gap a lot more.Frankly IE11 is actually pretty darn good. Even mobile IE11 isn't bad. Go figure.
eddman - Monday, August 18, 2014 - link
I did suspect the results. In most cases, IE10/11 come up first in battery life tests.I think you should also update the original article and add a brief explanation to the beginning and/or the conclusion, also linking to this article.
People are going to link the first article in other places, claiming it to be the most efficient, yet actually it's the worst.
Stephen Barrett - Monday, August 18, 2014 - link
To be fair, the original article stated that the Chrome 36 results at 3200x1800 were suspect due to lack of HiDPI support. In both the results page and on the final words page.However, I have updated the original article to link to this.
eddman - Tuesday, August 19, 2014 - link
Now that I think about it, why don't you rerun the test for all browsers at a lower, common resolution, say 1920 x 1080?Let's see how they do then.
Heavensrevenge - Monday, August 18, 2014 - link
BTW I found the way to make Chrome request the normal resolution timer vs the High Res timer (accidentally discovered it doing unit test during a power outage) lol. Set the active power plan to "Power Saver" and chrome's perf with degrade ~3x just as you were hoping for :P So you may need to re-test all the browsers under that power plan too in order to get the real "battery life".Stephen Barrett - Monday, August 18, 2014 - link
All AnandTech benchmarks run in "Power Saver" mode. Slightly customized from the default though.mkozakewich - Monday, August 18, 2014 - link
Wait, wouldn't that mean that you weren't even testing what you set out to test? If Chrome uses the regular timers on Power Saver, and you wanted to test how the fast clock affects battery life, you haven't actually tested it.Stephen Barrett - Monday, August 18, 2014 - link
Chrome does not use regular timers on battery saver mode (or ever). See page 3 of the original article. I verified that it was indeed requesting the high priority timer as the test was running.Also, see the second to last paragraph of the first page. It talks about this specifically.
Heavensrevenge - Tuesday, August 19, 2014 - link
Then explain this: I set my power plan to "Power Savings and start Chrome (Stable as you can tell by the version # in the report) AFTER setting to the power savings power plan and here:http://i.imgur.com/HlMxr3L.png to see chrome NOT requesting the higher timer WHILE running the sunspider javascript benchmark twice during the recording period
AND
https://mega.co.nz/#!thBUCKCT!RxVWNSEbw0b_-tCJCdrc... is the entire energy report that shows all the details of more chrome.exe processes vs just that single screen shot with 1 entry + the timer resolution to show u chrome doesn't ONLY request the high resolution timer no-matter what.
BTW the Dev version of Opera based on chrome ALSO doesn't force a high resolution timer but Firefox Nightly AND Chrome Canary seems to always request the high resolution timer for me so eat your own hat anand & staff.
josby - Monday, August 18, 2014 - link
Given the pace of software updates, this test strikes me as a little premature. Yes, HiDPI displays are the future, but so are Chrome 41, IE 13, etc. Right now, I'd imagine the vast majority of AnandTech readers are still on traditional displays. Tests of the software/hardware combos most of use are using now would be more useful than tests of software that will be long-outdated by the time most of us are on HiDPI displays.Gigaplex - Monday, August 18, 2014 - link
Why does a 20% drop in battery life seem extreme when rendering 4 times the number of pixels?DanNeely - Monday, August 18, 2014 - link
Because it went from slightly better than IE or Firefox to far worse than either of them.peevee - Tuesday, August 19, 2014 - link
Please, Macbook test. Please.drgigolo - Tuesday, August 19, 2014 - link
I would also really like to see test results from OS X. I only use Safari now because of iPhone sync and because it doesn't kill the battery if I accidentally have many tabs open with flash.