MediaTek Demonstrates 120 Hz Mobile Display
by Joshua Ho & Brandon Chester on January 7, 2015 5:54 PM EST- Posted in
- Smartphones
- Mobile
- Tablets
- Trade Shows
- MediaTek
- CES 2015
While we often don’t deeply discuss MediaTek as a company, they are a major force in the mobile space. Their SoCs are widely used in the mid-range and budget segments of the mobile market, and they have widespread OEM adoption due to their turn-key reference designs. However, despite this mid-range positioning we saw an interesting demo of 120 Hz mobile displays at their CES press event, which can be seen below.
While the video is in slow motion to demonstrate the difference, in practice the benefit of the higher refresh rate is still quite visible. Text scrolling and motion was visibly clearer and more fluid, although it’s possible that displays with poor refresh rates wouldn’t see nearly as much benefit. MediaTek claims that this feature would increase display power consumption by about 10%, although it’s unclear whether this is with dynamic refresh rate adjustment or constant refresh rate. Features like this seem to be part of MediaTek’s new strategy of bringing value to the mid-range, and it will be interesting to see if MediaTek’s focus on Asia will continue to pay off.
Facebook
Twitter
RSS
31 Comments
View All Comments
ddriver - Thursday, January 8, 2015 - link
I haven't tested windows devices, but iOS is a little better than the most recent android releases, but it is still far from ideal. The problem is not with Linux, but with the software stack. Linux can actually be more responsive than windows on desktop, especially if you build a real time kernel.name99 - Thursday, January 8, 2015 - link
The issue has nothing to do with how great the Linux (or WIndows, or Darwin) kernels are; it happens far higher up, in the frameworks.MS, in particular, has designed from scratch all the relevant Metro APIs to be concurrent --- they all take and return futures. This does a lot to prevent UI interactions and animations from being blocked by anything else that occurs on the primary app thread.
Apple are not as slick. They engineered Core Animation to run on a separate thread from the start, and they've retrofitted a bunch of the most important frameworks to take blocks as parameters, submitted to a GCD queue. But they don't have the future's technology of MS, so they can't as easily chain these async requests together or aggregate them. This will probably come soon With the next release of Swift (and maybe be retrofitted to Objective C). The technology for futures is in LLVM; but even so, Apple still needs a new set of Frameworks designed from scratch with this sort of Actor model in mind.
Google seem to be stuck in the 90s, with a 90s model of concurrency and a 90s model of animation. They (unlike Apple and MS) don't fully control their language. Java has had futures for a long time, but I don't know how powerful they are, how nice their syntax is, or how well they are integrated into the libraries. Certainly the Android frameworks (even today) as far as I know are not designed based on any sort of Actor model.
Basically interactive UI remains the same as always --- the more crud happens on your UI thread, the less responsive your device will be, so the key is ensuring that as much as possible doesn't happen on the UI thread. Step one is to make it POSSIBLE to move stuff off the UI thread. But that's only the start. Step 2 (about where Apple is) is to make it EASY to move stuff off the UI thread. Step 3 (where MS mostly is) is to make it EASIER to do stuff off the UI thread than to do it synchronously.
mkozakewich - Thursday, January 8, 2015 - link
I've never understood the whole 1ms thing. A 200Hz panel would take 5 ms to display anything, so you've got a pretty big window where you're a single frame behind. Maybe this would be less of a problem on a faster screen where you wouldn't be waiting up to 16.6 ms to see where you are.watzupken - Thursday, January 8, 2015 - link
Not sure if this is required on a cell phone to be honest. I rather have a decent speced phone where the battery can actually last, rather than the need to plug to the mains or battery pack almost daily. The race for higher resolution and bigger display is starting to become irrational from my point of view. So I wonder if this increased in refresh rate will actually bring about a useful improvement on a cell phone.Xinn3r - Thursday, January 8, 2015 - link
"although it’s possible that displays with poor refresh rates wouldn’t see nearly as much benefit."I don't understand this sentence, wasn't it comparing it to 120Hz? Isn't it obvious that poorer refresher rates (under 120Hz) would be worse?
Or is the display-capable 120Hz and refresh rate a different thing? If that's it, than it's really confusing explaining it using a sentence like that.
mkozakewich - Thursday, January 8, 2015 - link
I wondered, too. I came to the conclusion that they were saying the new chips enabled the use of 120Hz screens.Even then, it would be weird to wonder whether screens less than 120 Hz would perform worse. Yes, they would.
mkozakewich - Thursday, January 8, 2015 - link
Oh, unless screens need a refresh rate of 8.3 or less to sustain 120 Hz (which would be a hardware thing), and lower-quality displays of 10 ms or more would show less and less frames per second?ianmills - Monday, January 12, 2015 - link
I believe most display panels are capable of 120hz these days. The issue is with the chip/board that drives the display that is usually not capable of 120hzFor example, it is possible to buy a board for desktop LCDs that you can install inside the LCD to make it 120hz
stickmansam - Thursday, January 8, 2015 - link
Personally, I would prefer displays at 1600x900 at about 5 inches which gives a very good DPI still while not being wasteful imozodiacfml - Saturday, January 10, 2015 - link
They are now producing displays?