The Display: Like AMOLED, but Super

Did I mention Samsung also makes displays? The Epic 4G and the rest of the Galaxy S line are among the first to use a new type of active matrix OLED called Super AMOLED. The main difference appears to be that the capacitive touch layer and AMOLED are now integrated rather than laying on top of one another. This sounds a lot like the manufacturing technique used in Apple’s Retina Display. It’s supposed to reduce unwanted glare/reflections and improve the efficiency of the display.

The end result is very noticeable. The Epic 4G is much easier to read outdoors compared to the original AMOLED Android phones like the Nexus One:


Google Nexus One AMOLED (left) vs. Samsung Epic 4G Super AMOLED (right)

The Super AMOLED display is a nice improvement over the standard AMOLED. I’d even go as far as to say that it’s comparable to most LCDs in direct sunlight, at least when you’re looking at things that aren’t white. Displaying white is a problem for AMOLED screens, it eats up a ton of power since the technology is emissive without the use of a backlight.

Direct Sunlight

From left to right: Google Nexus One, Apple iPhone 4, Samsung Epic 4G

Shaded, Outdoors

From left to right: Samsung Epic 4G, Google Nexus One, Apple iPhone 4

The biggest selling point of AMOLED is its deep blacks, which the Epic 4G’s display delivers perfectly. The display is almost too contrasty. The bright blue text on black background in the settings pages just pops.

Brightness is an issue with the display. The brightest white I measured was only 300 nits:

Samsung gets away with a relatively dim device by having perfect black levels, but the display’s weakness is visible when reading web pages with mostly white backgrounds.


From left to right: Samsung Epic 4G, Google Nexus One, Apple iPhone 4

In the photo above, the Nexus One looks brighter, but the Epic 4G's white levels measure higher. I suspect this may be a Super AMOLED vs. AMOLED issue with our x-rite colorimeter. In practice the Nexus One has brighter pure whites while the Epic 4G has a brighter display in any other situation (e.g. home screen).

As AdamPflug correctly pointed out, the Epic 4G's web browser has a separate brightness setting which explains the difference in brightness above in the browser. In this case the brightness was set to around 20% of maximum on the Epic 4G.

Samsung includes a dynamic display feature that reduces brightness depending on the contents of the screen (there’s also the standard auto brightness based on ambient light). It’s not that noticeable when turned on in most situations but it reduces maximum brightness by about 100 nits. Again, this is mostly an issue with web pages that have a lot of white in them.

I’d say Samsung’s Super AMOLED is in the running for best display on a smartphone up there with the iPhone 4’s Retina Display. Apple has the resolution advantage, but Samsung has a huge contrast advantage. The former is nicer for reading text, while the latter is better for just about everything else.

Even if you don’t get the Epic 4G, Super AMOLED displays are where it’s at. They’re far more usable outdoors and you still get the contrast benefits of AMOLED.

Cellular & WiFi Performance Battery Life
POST A COMMENT

93 Comments

View All Comments

  • Ethaniel - Monday, September 06, 2010 - link

    I have also noticed that all Android phones out there do some kind of "breakdancing". You think it has something to do with Android, but I think it has something to do with Java. Now, Java devs will probably want to eat my brain after this... but Java sucks. Big time. Making Android's UI based on Java was a bad, bad, really bad move. About four three time slower than C++, it demands more memory... completely inadequate for a mobile environment. Reply
  • meatless - Monday, September 06, 2010 - link

    It's sad, the prevalence of Java FUD to this day. It's also bad to blame Java (the syntax), as you are unnecessarily conflating the Dalvik VM with desktop VMs such as Sun's.

    C++ is fast, sure, but there is a lot more to designing a platform than speed, and the Dalvik VM is more than fast enough. iOS's Obj-C implementation is also not C++ fast, but who complains?
    Reply
  • taltamir - Tuesday, September 07, 2010 - link

    1. both Javas are shit
    2. There is more to a platform then speed... but when you are designing a platform starved for processing power and that needs to sip electricity then it makes a huge difference.
    Reply
  • Penti - Tuesday, September 07, 2010 - link

    Most of the platform are actually C/C++ libraries and programs, where you glue your app in isn't that relevant. You need a framework for any mobile phone platform, but the resources that framework glues into thats where a lot of performance comes from and it's in C/C++. It's better to have an accelerated framework running on a virtual machine then an unaccelerated C++ one. Rendering of menus and such would be slower on the last one. Besides on Symbian it's QT-framework that rules now, not some ultra customized embedded framework. Memory requirements have gone up there too, but capacity have grown even more. Besides nobody wanted to write mobile apps to some badly designed and awkward C++ framework and API. Java syntax was a good choice therefor. Reply
  • taltamir - Monday, September 13, 2010 - link

    the fact that there are more considerations than just programming language when it comes to power and speed are obvious, as is that you could make a java app thats faster than a C++ app.
    Neither make java a good choice.

    BTW, I didn't personally comment about the issue of jerkiness, I was going on a tangent as a reply to what meatless said (specifically the socalled "java FUD")
    Reply
  • zizagoo - Monday, September 06, 2010 - link

    It's an Android problem. The cause of the "jerkiness" is that unlike iOS/WebOS/WP7, Android doesn't have a gpu accelerated ui. They supposedly did this because the G1 wouldn't support it at the time.

    http://code.google.com/p/android/issues/detail?id=...

    Gingerbread, which is supposedly showcased next month, should fix this.
    Reply
  • deputc26 - Monday, September 06, 2010 - link

    Thankyou! this is exactly it, give the man a medal. I don't know why Anandtech never mentions this. It should be ubiquitous knowledge in the android community. Reply
  • meatless - Monday, September 06, 2010 - link

    Also, the 3-4X speed difference on non-mobile platforms is greatly exaggerated. I always find http://shootout.alioth.debian.org/ a fun and FUD-free site. Reply
  • Iksy - Tuesday, September 07, 2010 - link

    Greatly exagerated? That site shows a 2.3x speed difference and it's comparring against Sun's fastest most optimizing version against g++. The unoptimized version is over 20x slower, you'll find it near the bottom of the list for compares. I do find it interesting that while they're satisfied with using an open source C (gnu) compiler, they do not include the open source java interpreter. They also do not include the Intel C compiler, even though they easily could and include the Intel Fortran compiler.

    In other words, is still in the ball park so say Java is 3-4x slower than the equivalent c++ code.
    Reply
  • dvinnen - Tuesday, September 07, 2010 - link

    Wait, so the Java syntax is what is slowing down Android? Because it doesn't run Java, it runs Dalvik.

    I would also like to see evidence that C++ is 4 times faster. Not saying Java is faster but it is fast enough. I say that as a Java developer who doesn't like the language and would rather use slower languages like Python
    Reply

Log in

Don't have an account? Sign up now