[Verizon Motorola Droid Turbo General] doitright:
Ok. Lets look at a few things;

1) The display. This is an AMOLED display, which basically means that the resolution claims aren't entirely honest. In green, yes, it is honestly 2560x1440 in green, but in blue and red, it is really only 2560x720. The nice thing about AMOLED is that it lets you turn on just those pixels that you are actually using. The nice thing about LCD (apple uses lcd) is that it looks MUCH MUCH nicer. So the use of qhd on amoled was actually a necessity in order to make the screen's "look" be similar to an LCD of a lower resolution. I mean think about it... a 1920x1080 amoled will have red and blue resolution of 1920x540. You'll notice that big time.

2) The performance tests are at native resolution. This does unfairly penalize higher resolution displays. By how much? Well lets put it this way; the apple phones are pushing out 1 and 2 million pixels for the 6 and 6+. This phone is pushing out a whopping 3.7 million pixels. Based on the number of pixels being driven, the Adreno 420 is quite thoroughly WHOMPING the apple phones. Nearly 4 times the pixel count and more than half the performance....

3) The benchmarks are questionable anyway, since they are synthetic, and they are running on totally different platforms. So many things depend on actual implementation. Something that is done wrong can have no impact on one platform, but huge impact on another. Just yesterday, I was debugging an opengles2.0 application on Android, it worked beautifully on a 2 year old exynos 5250, but turned to total junk on an (also 2 year old) snapdragon 8064, even pushing a smaller display. And to my surprise, it performed identically to the 8064 on a brand new 8084 (i.e. snapdragon 805). So what was the problem? A crazy loop that was linking thousands of duplicated shaders into thousands of duplicated programs. The code was incorrect in both cases, but for some reason, the exynos gpu driver figured it out and handled it decently. The adreno didn't, not that I would fault it for this, since the code was technically incorrect.

4) Just what the heck do these numbers mean? Its coming up with numbers in the *THOUSANDS* for benchmark results. Those aren't FPS. What ARE they, and why should you care? Do you know that Android caps FPS? Yep, the cap is 60 FPS. Apple doesn't seem (from what I can tell) to do that. What this means, is that benchmark results on Android are, in some cases, *artificially limited* to a sensibly high number. You don't need it to go over 60 FPS. So what does this mean in a benchmark? It means that if apple chugs along with it mostly preferring 40 FPS with a few bursts as high as 200 FPS and a couple of spots as low as 5 fps, and averages at 70 FPS, then it will "score better" than an Android device that is stuck at 60 FPS the whole way through. Fair benchmark? No, of course not.

Here is the take home message from all this;

You CANNOT compare benchmarks between dissimilar devices. They DO NOT show you an accurate comparison between multiple dissimilar devices. The correct application of benchmarking is to compare things that are almost THE SAME before and after some small change. I.e., change this code from this to this, causes 10% improvement in FPS.