Display Measurement

One of the more significant characteristics of the Nexus 6P is the device’s AMOLED screen. Similar to last year’s Nexus 6, Google has chosen to employ the 6P with a panel from Samsung. While the Nexus 6’s panel seemed to lack in quality, both power and image quality wise, the 6P’s unit is quite excellent.

The screen is very clear and offers excellent homogeneity. Ever since the first AMOLED devices came out a few years ago Samsung has managed to steadily advance the technology with improvement with each yearly generation. The Nexus 6P’s can be said to rank well among the Note 4 or Note 5 in terms of image quality, and it seems the 6P’s lamination actually provides slightly better viewing angles than what’s found on Samsung’s devices.


Settings => Developer Options => Picture Colour Mode

Before getting to the results, I'd like to mention that I tested both the device's default colour calibration as well as its sRGB calibration. This setting is rather hidden for the average user: You have to enable the developer options menu by tapping repeatedly on the "Build Number" found in Settings => About Phone, after which the menu will appear under the global settings menu. It's a pity that Google didn't make this option more accessible via the general display settings, but it will be required to access if you care about accurate colour reproduction on the Nexus 6P.

We start by measuring the maxium brightness of the 6P. As always, our display testing is done with an X-Rite i1Pro 2 spectrophotometer as our measurement hardware, in conjunction with SpectraCal's CalMAN software suite and our own workflow to be able to get an accurate display characterization.

Display - Max Brightness

The Nexus 6P manages to drive the screen at up to 348nits, a quite satisfactory level of brightness that matches the Note 5’s characteristics. Unlike Samsung’s devices, it seems the Nexus 6P has no overdrive function which vastly increases the luminosity under high ambient light and auto-brightness. Nevertheless, I’ve had no issues whatsoever in terms with outdoor visibility (Although that’s not a very convincing statement for European winters) as the screen offers excellent contrast.

While still on the topic of brightness, I was actually disappointed to discover that the device’s software is set up so that the brightness slider bottoms out at 8.5 cd/m². While doing the power curve measurements I discovered that the panel and driver is actually able to go down as low as 1.5 cd/m², making this one of the rare devices whose panel can go that low. I’ve become accustomed to using phones at around 2 nits at night and in bed, so 8 nits was suddenly brighter than I wished for. Changing the minimum value of the stock brightness slider wouldn’t be a very complicated task so I hope Google considers this for future maintenance releases.

Edit: After further testing I discovered that it's possible to get to 1.5 cd/m², but only if Adaptive Brightness is enabled and one is located in a dark environment, as brightness without AB offsets the range of the brightness slider.


sRGB:       

Default:     


sRGB
Default

Display - Grayscale Accuracy

Moving on to the greyscale accuracy tests, we see the Nexus 6P behave very well. At a dE2000 of 1.99 the 6P lands as one of the best devices in terms of accurately reproducing greyscale content. There is however one problem, and that’s the average gamma of 2.41. This causes content to be darker than what it’s supposed to be and also has the effect of making colours seem more saturated. The default colour calibration doesn't differ very much from the calibrated sRGB norm, as it shows only a slight disadvantage with a dE2000 of 2.29.

Display - White Point

In terms of colour temperature, the 6P is slightly on the warm side as it comes at 6388K at 200cd/m². The latest generations of AMOLED screens seem for some reason to always slightly undershoot the target D65 (6500K) white, making the screen just slightly warmer than it should be.

 
sRGB versus Default

Display - Saturation Accuracy

Moving on to the saturation accuracy measurements, we’re presented with some outstanding numbers from the sRGB mode as the 6P manages to deliver an excellent dE2000 of 1.41. At these accuracy levels I would argue that manufacturers would need to resort to individual device colour calibration to be able to provide even better results, as for example even by manually calibrating my own daily driver I wasn’t able to surpass a dE lower than 0.95. Unfortunately the default mode just fares little better than last year's Nexus 6, making for some very saturated colours. I tried to match the reproduced gamut against several standards but I didn't find anything that resembles the Nexus 6P's default mode, meaning this is not an AdobeRGB or DCI large gamut calibration.

 
sRGB versus Default


sRGB


Default

Display - GMB Accuracy

Moving onto the Gretag MacBeth set of commonly encountered colours we see the Nexus 6P fall behind when compared to its excellent greyscale or saturation results. Because the gamma on the 6P’s screen is too high, it causes the luminosity component of colours to be lower and thus, as can be seen in our comparison strip, they will appear darker and slightly more saturated than they should.

On the default settings the GMB accuracy is farther off as expected. There's not much to say here as it's a deliberately inaccurate mode that gives higher priority to vibrant colours as opposed to accuracy.

Overall the Nexus 6 screen ranks among one of the best. It’s a bit of a pity that the gamma calibration was slightly off under the sRGB profile but otherwise the 6P excels in all other metrics. Samsung currently offers the best quality displays and Google and the Nexus 6P takes full advantage of that fact.

Display Power

While we can safely declare that the Nexus 6P offers excellent image quality in its display, one aspect that hasn’t been characterised as much in the past was the power consumption and the resulting luminance efficiency. The Nexus 6 suffered from a quite inefficient panel that resulted in a battery runtime that was lower than expected from a device of its configuration. I was quite worried when I saw that Huawei chose a quite inefficient AMOLED screen for the Mate S, as that proved to be a double-edged sword for the device, as it also offered great image quality but at a great cost in power efficiency.

For the Nexus 6P, getting an accurate power curve for the screen was exceptionally hard as the fuel-gauge of the PMI8994 power management IC of Snapdragon 810 devices updates only rarely and therefor becomes unusable for many power measurements. So to properly characterize the power draw at increasing brightness without spending several hours for each measurement point I hooked up my measurement equipment to the USB power of the 6P. Once a phone’s battery cell is fully charged it will usually switch to be fully powered by the power supplied by the connector as long as it’s able to provide sufficient power. The downside of this method is there’s a significant unknown delta due to the inefficiency of the PMIC converting the input 5V to the system’s internal 3.3V. Nevertheless with some help of some test measurements via the internal fuel gauge I was able to compensate for this difference, which gives us the following power curve:

The Nexus 6P seems to have a base power consumption of around 450mW with a fully black screen, meaning no pixels are powered. This comes in to be similar to what we’ve measured on the Note 4 Exynos, but is still about ~100mW higher than devices featuring more efficient SoC platforms. At maximum brightness, the device consumes about 1.59W, a tad under the 1.7W that the Note 4 used. Some readers might already figure out where I want to go with this, as there’s been plenty of discussion and questions in regard to the efficiency of the panel that will be employed on the Nexus 6P.

To get a better overview, we plot the screen luminance power across several devices in a table and calculate the overall efficiency by dividing that figure by the screen’s area footprint. As a reminder, the screen luminance power is the delta between a screen’s black (or minimal brightness) power to full white at a given brightness, in this case 200cd/m².

Screen Luminance Power Efficiency
100% APL / White
Device Screen Luminance Power
at 200cd/m²
Luminance Power (mW) /
Screen area (cm²)
Efficiency
LG G4 354 mW 4.11
Meizu MX4 345 mW 4.14
Huawei P8 ~341 mW ~4.43
Meizu MX4 Pro 386 mW 4.47
Samsung Galaxy Note 5 504 mW 5.64
Samsung Galaxy S6 442 mW 5.99
Huawei Nexus 6P ~615 mW ~6.88
Samsung Galaxy S5 532 mW 7.21
Samsung Galaxy Note 4 665 mW 7.22
Samsung Galaxy S5 LTEA 605 mW 8.20
LG Flex 2 765 mW 8.89
Samsung Galaxy S4 653 mW 9.22
Huawei Mate S ~769 mW ~9.24

At a 200nits and a luminance power of around 615mW, the Nexus 6P’s panel falls in between the Note 4 and the Note 5’s/Galaxy S6’s in terms of efficiency. We can’t clearly attribute any certain emitter generation to the device, but it looks to be about 5% more efficient than the Note 4’s but still a considerable 16% less efficient than the Note 5. It was starting with the Galaxy S6 that I’ve considered AMOLED screens to no longer be in at a disadvantage to LCDs when it comes to efficiency in every-day use-cases. Since the Nexus 6P falls behind that it means we should expect slightly less run-time than comparable LCD devices. Let’s continue on to the battery life results to verify this assessment.

GPU Performance & Device Thermals Battery Life & Charge Time
Comments Locked

219 Comments

View All Comments

  • tuxRoller - Monday, December 21, 2015 - link

    Do you have a reference for saying that they don't make use of idle loops and dvfs?
    If that's the case, and I don't think it is, then what apple has done is even more amazing: the highest performing soc available is capable of being run FLATOUT for half a day on their tiny batteries. If they made use of even minimal power saving a9 devices would last for DAYS.
  • tipoo - Tuesday, December 22, 2015 - link

    I think they probably meant the GFXbench battery run test and final run FPS test, every other SoC throttles down by the last one, where A9 keeps a high speed but kills the battery sooner.

    I think that speaks more to the throttling issues of other SoCs, even if it accidentally raises gaming battery life.
  • tipoo - Tuesday, December 22, 2015 - link

    "anyone who knows hardware knows single threaded architectures will score higher"

    So explain, please. And neither iOS nor A9 are single threaded, all SoCs since the A5 with the exception of the A8X are dual cores, A8X being tri-core. iOS scales to threads just fine as shown with the third core being used just fine in the A8X. Apple just chose higher per-core performance, since it's more usable than the same performance spread across 8 cores.
  • NEDM64 - Monday, December 28, 2015 - link

    "Android was built to be a true multi-tasking OS...Apple was not..."

    Fanboy tears?

    "Apple" OS's, based on their open-source project, Darwin, are microkernel-based, non-peremptitive multitasking operating systems.

    Just like OS X, iOS is a truly multitasking OS.

    And if you want to cry even more, then explain why the Pixel C doesn't offer side-by-side multitasking and iPads with iOS 9 do?
  • usman_raza - Wednesday, December 16, 2015 - link

    Finally,
    2nd Comment :)
  • Anustart - Wednesday, December 16, 2015 - link

    Loser
  • AL KASR - Wednesday, December 16, 2015 - link

    thanks, but what about random read and random write for the nand, which is the most important!
  • Andrei Frumusanu - Wednesday, December 16, 2015 - link

    I had to leave them out due to an issue with the 3.6 version of the benchmark not being able to complete those sub tests, we'll be investigating the matter and in the future we'll also migrate to AndroBench 4.0.

    Here's the 4.0 scores for the device:

    Encrypted: 75.7MB/s seq read, 40.6MB/s seq write, 7.4MB/s rand read, 1.0MB/s rand write.
    Unencrypted: 179.7MB/s seq read, 52MB/s seq write, 14.73MB/s rand read, 6.3MB/s rand write.
  • Olaf van der Spek - Wednesday, December 16, 2015 - link

    Why do the random scores take such a hit from encryption? The SoC should be fast enough to encrypt 6.3MB/s so I can't think of a reason for rand write to drop to 1.0MB/s..
  • Andrei Frumusanu - Wednesday, December 16, 2015 - link

    The random test uses 4KB segments and it's likely that due to that there's a lot of system overhead when making such short I/O operations.

Log in

Don't have an account? Sign up now