Recently on the podcast, Anand mentioned that I was looking at how the Galaxy S5 performed when running benchmarks underwater. This ultimately started after the initial Galaxy S5 review was finished, as I started to test just how well the IP67 functionality worked. For those unfamiliar to how the Galaxy S5 achieved this ingress protection (1 meter depth for 30 minutes), the phone has effectively been designed from the ground up to prevent water ingress.
First, a rubber gasket on the back cover helps to keep out water from critical areas of the phone, as seen below. While the photo doesn't show it very well, there's another snap in the area enclosed by the rubber gasket to ensure that a tight seal is created.
Second, the USB port has a water-sealing cover that latches tight to keep water out, as seen below in the closed position.
Finally, the entire phone has effectively has two midframes, one on the display assembly and the other serving as a mounting point for the logic board. This means that all the screws are hidden underneath the display assembly, which is glued on, as seen below in iFixit's teardown. The entire phone stays tightly assembled, without any risk of screws backing out and making it possible for water to enter the phone.
While it was an interesting party trick to pour water all over the phone, ultimately the most interesting aspect would be examining how water would affect the performance of the Galaxy S5. Doing such a test would also be a good way to verify that the phone would be able to handle submersion. As shown by our T-Rex rundown tests in the Galaxy S5 review and by the graph below, the HTC One (M8) noticeably pulled ahead of the Galaxy S5 in performance by the end of the test. We attributed the difference in sustained performance to the difference in the build of the two phones. The M8's metal unibody chassis simply does a better job of removing heat from the Snapdragon 801.
As Anand said, I ultimately didn't find much in the way of interesting results for our standard benchmarks. Instead, what ended up being interesting is the battery rundown test. Most of the results ended up being the same or less than what Anand published for the Galaxy S5 review. At any rate, analyzing the T-Rex rundown test proved to be the most useful in terms of data. For reference, these tests were conducted at around 68-70 degrees Fahrenheit or 20-21 degrees Celcius ambient air and water temperature, which came out of the tap. Both tests were run for around 25 minutes to ensure that the IP67 rating wasn't exceeded. This ultimately means that FPS differences will be somewhat difficult to see until late into the test, but the trend is noticeable, as seen by the graph below. With a few more runs, I'm sure this would be more apparent, but in the interest of having a Galaxy S5 to test against other phones in the future, I'll have to hold off for now. At any rate, the water-cooled version of the Galaxy S5 seems to maintain a steady ~28 FPS, which effectively means that the phone doesn't throttle at all given room temperature water.
While the FPS plot doesn't seem to show much, looking at the graph of battery temperatures seems to show the major difference that water cooling can make, especially for a smartphone that is made to be passively cooled by ambient airflow. Unfortunately, this data isn't quite as neat, as I haven't found a utility that dumps data from temperature sensors into a CSV file. At any rate, the trend is obvious enough. In the images below, the right screenshot shows battery temperature when running T-Rex in air, while the left screenshot shows the battery temperature when running T-Rex in water. The GS5 in air appears to peak around 35 degrees Celcius given the conditions, a delta of around 15 degrees Celcius from the ambient temperature, while the GS5 in water appears to peak around 22-23 degrees Celcius, or only a degree or two above ambient temperatures at best.
The results speak for themselves in this case, and while this is ultimately a bit impractical from an ease of use standpoint, it definitely is possible to do, and leads to some interesting possibilities from a custom ROM/overclocking standpoint. As always, it's worth going over why these results were observed. In short, while the water was effectively at the same ambient temperature as the air, the difference in heat dissipation and throttling was noticeable, even just ten minutes into the test. This is because of water's properties compared to air that make it especially well suited to moderating temperatures. The first is thermal conductivity, which means that heat from the phone is transferred more quickly into the surrounding environment. The second is water's high specific heat capacity. This means that the water requires a great deal of heat energy to increase in temperature, which means that the environment around the phone is also less likely to heat up. Finally, the relatively high density of water relative to air means that more water can be in a given volume than a given volume of air, which means that more particles have to be heated before the temperature of the surroundings will increase.
In short, all of these factors make water a much better coolant than air. While the real world use cases for this would be few and far between, it definitely does make for a neat effect and helps to reduce the impact of thermal throttling on benchmarks. It's not hard to think of places where the water resistance would come in handy though, especially when it comes to using the device while taking a shower/bathing or while at the pool. However, based upon the build of the phone, it is still inadvisable to take it to the beach as the sand and salinity of the water would likely cause corrosion of the sealing measures and damage the phone.
Revisiting the Fingerprint Scanner
Back when I first used the fingerprint scanner, I effectively said that it was only usable with two hands, and required slowly swiping the finger down the sensor in a consistent manner, but after sufficient experimentation, I've managed to figure out how to actually get it working with one hand. Of course, the key is always to make sure that the finger is enrolled properly. This basically means that swiping the same way one would unlock the phone is absolutely crucial. The big issue here is that the enrollment process seems to be far less selective of which prints it will accept than the actual unlock process itself, which means it takes trial and error to establish whether the enrolled fingerprint will actually make it possible to unlock in the same manner. Various issues like make the fingerprint sensor an enormous friction point in the whole experience, as attempting to unlock until the maximum number of attempts is reached is not uncommon, and there are often noticeable delays between swiping and an indication of success or failure of the fingerprint scanner.
At any rate, it is satisfying when it works on the first try, as in those cases it beats a pattern lock as shown by the gif above, on the right. However, the times when failure after failure occurs, it's frustrating enough to switch back to a pattern lock or no lockscreen at all. An example of this can be seen by the gif on the top left. I'll continue to look into trying to get the fingerprint sensor to work, but as it is, there is significant room for improvement. Perhaps a software update will help to resolve some of the issues present, but some issues, such as the reduced tactile feel of the home button and awkward swiping gesture cannot be solved by software. While I'd still prefer having the fingerprint scanner to not having the fingerprint scanner, this is the first time that I've actually gone back to using a standard pattern lock on a phone with a fingerprint scanner for any period of time.
Quibbles with usability aside, I question the security of this fingerprint scanner, as in my experience there's no need to enter in a password if I reboot the phone, and even if I exceed the number of allowed attempts, on my unit I find that getting another attempt is as easy as turning the screen on and off again with the power/sleep button.
Display: Professional Photo and Adobe RGB
As some other websites and readers have mentioned, Pro Photo is apparently meant to target Adobe RGB, rather than sRGB. While I've discussed why gamuts larger than sRGB can be a problem on an OS like Android that doesn't support ICC color profiles, this doesn't mean that I object to a display that supports gamuts larger than sRGB. If anything, this will be the only way to push the industry forward to a wider color gamut standard in the long run.
As always, all of our display tests are run using CalMAN 5 with a custom workflow.
For this display characterization, I deliberately chose not to look at grayscale again as I've already discussed those results in the Galaxy S5 review. As a quick recap for those that haven't seen the review, the Galaxy S5 has good white point in grayscale, however there's a noticeable green tint to all whites and grays, likely because it lets Samsung hit much higher brightness values.
In the saturation sweep, Pro Photo is approximately as accurate in Adobe RGB as Cinema mode is in sRGB. However, looking at the saturation sweep shows some severe issues with calibrations of red, green, cyan, and magenta. Each of these colors have different sets of issues, so it's worth going over each of them. In the case of red, there's a bit of overshoot at 100%, and it seems to have offset every saturation as a result, making everything redder than it should be. In the case of magenta, there's no issue with saturation compression or going noticeably beyond the gamut, but it's skewed towards red. The issues with green and cyan are mostly similar, and likely constrained by the native gamut of the AMOLED phosphors, as it seems both are within the Adobe RGB gamut, and while 20-60% saturation is generally linear, 80% and 100% have been compressed quite closely together, likely an attempt to compensate for the lacking native gamut. Cyan is also noticeably skewed towards the green side, especially at 100%. As always, the hope is that Samsung will continue to improve calibration and introduce mechanisms to compensate for OLED aging to maintain color accuracy. Overall though, for a mobile display it's great that it even comes close to Adobe RGB, as most LCD displays generally cannot go far beyond sRGB.
After getting to spend more time with the Galaxy S5, I've been able to get a more nuanced view of the device. The more time I spend using both the Galaxy S5 and One (M8), the more mixed I become on both. Ultimately, neither is truly better than the other. Both phones definitely feel too big now, especially compared to the One (M7) and Galaxy S4, which were phones that I found to be perfectly usable and not significantly harder to use than the 4.3"-screened phones of 2011 and and 4.8"-screened phones of 2012. I sincerely hope that the size creep occurring here comes to an end now, or even regresses.
For the Galaxy S5, there are various issues that remain irritating. Despite being able to use the fingerprint sensor with one hand, it still regularly fails for no apparent reason. The display's strange green tint to whites and grays is noticeable, and TouchWiz feels noticeably slower than Sense 6 despite turning off the S-Voice home button toggle and doubling the animation speed. The water resistance measures also noticeably reduce the amount of heat that the phone can dissipate, which effectively nullifies the gains made by the higher CPU bin. It's also a bit disappointing that Samsung continues to push 1.1 micron pixels without OIS in the camera module to try and compensate for lower sensitivity.
Despite these issues, the Galaxy S5 remains a solid choice. The closest competitor, the HTC One (M8), is equally imperfect, although addressing this is best left to another article. In general, it seems that this year, the major Android flagships will all be flawed in their own ways, for better or worse. It certainly doesn't make sense to upgrade this year if you already have a flagship that launched in 2013, although other OEMs may surprise us at some point further down the road.