Display

In recent times we've seen a tremendous improvement in smartphone and tablet display quality. It began with high end flagship phones, and eventually trickled down to more budget oriented smartphones. Even a $130 smartphone like the 2015 Moto E can have a decent IPS display. However, I'm hesitant to describe the Zenfone 2 as a "budget" smartphone. While I don't mean for the word to have negative implications, it's often interpreted as meaning low quality or cheap. The Zenfone 2 is better described as an inexpensive smartphone. Much like the OnePlus One did when it was released, the Zenfone 2 offers some very serious hardware at a price much lower than what has become the going rate for flagship smartphones.

The display in the Zenfone 2 is a 5.5" 1920x1080 IPS LCD panel. This is another specification that you would expect to see in a $650 flagship device that is instead inside one that starts at $199. While phones are now moving to 2560x1440, on RGB stripe panels I don't feel that there are significant benefits to moving past 1080p even on 5.5" displays. On top of that, a display's resolution is just one of many attributes that contributes to its quality. Color accuracy, brightness, and contrast are all important aspects of a display. To accurately characterize these areas of display performance, we use SpectraCal's CalMAN 5 software and X-Rite's i1Pro 2 spectrophotometer.

Display - Max Brightness

Display - Black Levels

The Zenfone 2 appears to be off to a good start. Black levels are very low among our LCDs, and the max brightness is somewhat low but not terrible by any means. I never had any issues when using the Zenfone 2 outside, although it was definitely not as comfortable as the Galaxy S6.

Display - Contrast Ratio

The slightly low max brightness and above average black level results put the Zenfone 2 right in the middle of our LCD devices when it comes to contrast ratio.

Unfortunately, these numbers are somewhat misleading. This is because the Zenfone 2 makes extremely heavy use of dynamic contrast and contect adaptive backlighting (CABC). I have never used another device with such dramatic shifts in backlight power. The best example I've found is when switching from an all black to all white screen at max brightness. While this is obviously an extreme case, it illustrates the behavior that is occuring very well. At the moment you switch to white, the brightness of the display is around 170 nits. Over the next few seconds, that brightness rapidly increases to the 390 nits you see in the results above. This is an enormous jump in brightness, and it's very easy to see with your own eyes.

One last thing I'd like to note about the brightness is that the 100% setting on the built in brightness slider is not actually the max brightness that the display is capable of. The max you can achieve using the slider in the Settings app is 319 nits, which is around 82% of the 390 nit result you can get using applications like Brightness Adjuster from Google Play.

Display - White Point

Display - Grayscale Accuracy

Greyscale accuracy on the Zenfone 2 is very average. The display is too blue, and this can be seen in the reproduction of shades of grey as their brightness goes beyond 15%. The gamma is also extremely irregular, and continually curves upward. This is the result of ASUS's heavy dynamic contrast and CABC. The brightness reductions with darker shades makes the display slower to move out of the shadows, which you can see in the color comparator chart above. Again I must reiterate that the color comparator is a relative color difference, as the bottom half which displays the "target" colors will be impacted by any inaccuracies in the display you use to view it.

Unfortunately, there's not much that can be done to improve greyscale accuracy when CABC is used heavily. Testing with constant APL patterns to try and avoid the brightness shifting did bring the gamma down to 2.4, but because the display still has a blue shift and the gamma is still too high, the average greyscale deltaE was around 4.5 which is still fairly high.

Display - Saturation Accuracy

Saturation accuracy ends up being noticeably better than greyscale accuracy on the Zenfone 2. Blue and green manage to stay below the dE target of 3 for all saturation levels, while all the other colors hover somewhere between 4 and 6 on average. An average deltaE across all colors of 3.754 is not terrible by any means, and I don't think Zenfone 2 buyers will have any complaints about the accuracy of primary and secondary colors.

Display - GMB Accuracy

Unfortunately, the inaccurate greyscale and gamma of the Zenfone 2 comes back to haunt it in the Gretag MacBeth ColorChecker test. This test measures the accuracy of various color mixtures that are common in the real world, and the Zenfone 2 misses many of them by a significant degree. What's even more unfortunate is that the highest errors are in mixtures of yellow in red, with the largest error of all the colors tested being light skin tones. If there's one color I want a display to get right, it's skin tones.

The overall display performance of the ZenFone 2 is mixed at best. I'm glad it basically has the full sRGB gamut, and is fairly accurate with saturations of primary colors. However, it doesn't do very well when it comes to shades of grey, and it also has slightly lower accuracy with color mixtures than I had hoped. Devices like the 2015 Moto E show that it's possible to get close to that dE error target of 3 even on an inexpensive smartphone. I would still say that the ZenFone 2 has the best display at this price point purely on the merit of its pixel density, but I really wish that the calibration was better than it is.

Introduction and Design Battery Life and Charge Time
POST A COMMENT

148 Comments

View All Comments

  • der - Tuesday, May 26, 2015 - link

    Sweet review mates. Y'all the best! Reply
  • Daniel Egger - Tuesday, May 26, 2015 - link

    Two things:
    1) The x86 problems are very real; about any serious Android application contains native code for performance reasons, the rest are very non-demanding gimmicks or simple games. There're still plenty of application which do not even attempt to run on x86 which can be easily seen by e.g. checking the F-Droid repository with the app. And of those which do run quite a few simply don't work correctly; I've found quite a few of those in the Humble Bundles. My suspicion is that the developers do compile them for x86 but do not really test them on that platform...
    2) Those Silvermont cores do have decent performance but I've yet to see a single implementation where battery life doesn't suck. One discovery I've made is that those devices are very reluctant to go into deep sleep, even with some tweaking they'll usually stay on the lowest possible frequency most of the time. Could be that the software is not quite ready to properly handle those Intel cores or they simply suck...
    Reply
  • MikhailT - Tuesday, May 26, 2015 - link

    Both are software issues. Google doesn't have any incentives to stick with ARM only, they'd want to work with Intel to fix these issues.

    At my work, we had an issue where our app would crash on Intel devices, it took us a few weeks to figure out that it was a low-level bug in Android. We filed a bug report but no news if Google or Intel will fix it. We managed to work around it but it was difficult and took a lot of time.

    The latest rumors is that Android M is supposed to work on the battery issues. Hopefully, that includes optimization for Intel SoCs.
    Reply
  • kpb321 - Tuesday, May 26, 2015 - link

    I was surprised that the review seemed to skip this entirely. It is certainly an issue when dealing with x86 android phones. Theoretically any app that doesn't include NDK "should" work fine on x86. My experience with Android phones/tablets was that I don't ever recall installing a single app that had NDK in the permissions list so it didn't seem like it was very common to me. On the other hand I've never actually had an intel tablet to actually see how good or bad it was. Reply
  • Brandon Chester - Tuesday, May 26, 2015 - link

    I also reviewed the Venue 8, and like I said in both this review and that review, I have never found a single app that doesn't work because the SoC is x86. A lot of people like to say that there are lots of apps that have issues, but they never seem to name any so there's no way for me to actually confirm that. If people do know of some problematic apps please let me know via email or Twitter so I can take a look. Reply
  • Muyoso - Tuesday, May 26, 2015 - link

    An app called Photo direct that I use for work crashes instantly when launched. Reply
  • rocketbuddha - Wednesday, May 27, 2015 - link

    I bought a Dell Venue 8 with KitKat
    http://www.bestbuy.com/site/dell-venue-8-8-intel-a...
    and found that it was the POS.
    Dunno if it was 1GB RAM that came with it, but it was hanging even while opening tabs in chrome/stock browser.

    With Lollipop, Google officially has both a ARM as well as x86 version it tests and releases. Pre-lollipop it was Intel who customized Android to work with its Atom processors.
    Reply
  • Maleficum - Saturday, May 30, 2015 - link

    Brandon, you'd be really surprised to know that most apps in the top charts are using NDK.

    Google claims that 85% apps are written in Java. I'm not saying it's a lie, but it is far from realistic since most apps in the top charts - apps most people use most of their time - are NDK based.

    Even more surprising would be the fact that roughly half of these apps contain ARM binaries only, thus forced to run via binary translation that results in a performance reduction of roughly 70% while the power consupmtion doubles.

    In that sense, your article is misleading IMHO, simply repeating Google's claims.

    http://www.theregister.co.uk/2014/05/02/arm_test_r...

    I think it's clear why so many apps are NDK based: Java isn't simply the right language for computationally intensive apps, and primitive apps written in Java cannot make it into the top charts.

    And app developers aren't interested much in supporting x86 natively considering the tiny market share. No one can blame them for neglecting x86.

    That's the reason why I'd never buy nor recommend x86 Android phones, and Intel having difficulties getting foothold in mobile segment.

    I think it would be worth an investigation and probably a separate article.
    Reply
  • Thunderc8 - Saturday, May 30, 2015 - link

    I have installed all known apps and then some and all working perfect and super fast. If what you say is true then Intel CPU is a beast since it looses so much performance and at the same time is so Damn fast. Reply
  • coolied - Wednesday, May 27, 2015 - link

    NDK wouldn't be in the permissions list, it simply means the app was coded in C++ and not JAVA. Unfortunately, most apps you would WANT to run and run WELL are written in C++ aka most 3D games. Reply

Log in

Don't have an account? Sign up now