For several years now, mobile device manufacturers have been in a race to push the pixel density of mobile devices higher and higher. The race began with the iPhone 4 “Retina” display – an at the time impressive 330 pixels per inch (PPI) 960x640 3.5” display. Keen to trump the Retina moniker, makers of Android devices soon churned out devices with displays with PPIs of 440 and higher, with the current push to 2560x1440 displays in 5.5” or smaller sizes which yield an amazing 500+ PPI. Next up was a similar race in the tablet space, with 1280x800 soon giving way to 2560x1600 displays, but this time in a 7” to 10” form factor.

All the while, the lowly PC and Mac chugged along with displays that could hardly be called impressive. The standard LCD display of just a few years ago would hover somewhere around 96 PPI, and it was often lower. A 17” LCD with a resolution of 1280x1024 wasn’t an accident – it was exactly 96 PPI, which is what the PC and Mac would render at by default. High resolution laptops would barely squeak past the 120 PPI range. These lower densities – though decent for the longer view distances of desktop monitors – have until recently not been improved on, highlighting the gap in progress between the two devices categories.

Further complicating matters, desktops and mobile devices have always differed in how they use resolution when it is increased. On a mobile device, higher resolution has been used to increase image quality, while higher resolution displays on a desktop were released as part of physically larger displays and used to increase the amount of work you can do. Mobile devices have had one big advantage: they are backed by new operating systems that are built for higher resolution out of the box, and there is no back catalog of legacy applications to deal with. Phones and tablets can easily deal with high resolution displays, but for the PC and Mac, things are not so simple.

In 2012, Apple launched the 15.4” Retina MacBook Pro. At the time it was far and away the highest PPI laptop available. It took a lot of work for Apple to ensure a high resolution display was usable because for really the first time, increased resolution on a computer was used to improve image quality rather than simply to increase screen real estate. How they achieved this was nicely explained by Anand back in 2012. However, OS X wasn’t perfect; certain applications didn’t behave as well as they should have, which resulted in some applications having blurry text or other UI issues. Still, Apple was able to make the Retina display work, and for the applications that were Retina aware, the result was a fantastic experience. If developers updated their applications, their clients could enjoy the high resolution clarity that had already taken over the mobile space.

But what about Windows? Windows Vista, and then Windows 7, both had support for higher DPI (Dots Per Inch) settings; even lowly Windows XP had some support for DPI scaling. The main issue was that there was no market force pushing for High DPI (in the operating system and APIs, it’s referenced as DPI as opposed to the PPI of a display) like there was with the Retina MacBook Pro. OEMs were happy to sell consumers low cost, low resolution 1366x768 TN panels for years. If people don’t demand better, most OEMs are unlikely to provide them better than the basics in such a low margin industry.

High Resolution Laptops
Brand Model Screen Size Screen Resolution Pixels per inch
Acer Aspire S7 13.3" 2560x1440 221
ASUS Zenbook UX301LA 13.3" 2560x1440 221
Dell XPS 11 11.6" 2560x1440 253
Dell XPS 15 15.6" 3200x1800 235
HP Spectre 13t-3000 13.3" 2560x1440 221
Lenovo Yoga 2 Pro 13.3" 3200x1800 276
Lenovo X1 Carbon 14" 2560x1440 210
Panasonic Toughpad 4k 20" 3840x2560 231
Razer Blade 14" 3200x1800 262
Samsung ATIV Book 9 13.3" 3200x1800 276
Toshiba KIRAbook 13.3" 2560x1440 221

What changed was a combination of High DPI tablets and the Retina MacBook Pro putting pressure on the PC industry to offer something better. It has taken a long time, but finally quality displays are something that are important enough to consumers for every single major OEM to now offer at least one, if not multiple, devices with High DPI.

History of Windows DPI Scaling
POST A COMMENT

114 Comments

View All Comments

  • Antronman - Tuesday, April 15, 2014 - link

    4k display on a notebook would have to be achieved with top-end mobile graphics.

    The display would likely need a 30Hz refresh rate to avoid screen tears. It would really only be something practical for 2D artists who do a lot of their work on the go.

    As far as scaling, I imagine it would work exactly the same as on an external monitor.
    Reply
  • darthrevan13 - Wednesday, April 16, 2014 - link

    Being a week before the Toshiba Satellite P55t no one has any answer but looking at their 65L9300U UHDTV with 60hz and real HDMI 2.0 that launched not too much time ago things aren't looking so bright because when put on a lower resolution things get a little blurry. The scaler is hardware based (to keep up with the enormous resolution and refresh rate) not software based so until someone makes a silicon that viably handles 4K, 1080p and 720p you'll be stuck. Reply
  • B3an - Friday, April 18, 2014 - link

    I don't know why people like you think that 4k is hard to do. An average GPU can easily handle 4k @ 60hz. It's only for gaming that requires something more powerful. Reply
  • B3an - Tuesday, April 15, 2014 - link

    Brett - nice article. One thing i wanted to point out though is that the workaround you mention for Chrome does not work. Turning on HiDPI still has issues. The UI is messed up and pixelated, and text still isn't rendered correctly - the spacing of the letters is messed up. You can also see this in your text screenshot, look at the word "committing", the two M's are too close together. With other letters some are too far apart (depends on the word). Chrome is just screwed up, it's best you FF or IE. FF has small issues though but the text atleast renders correctly. Reply
  • Tujan - Wednesday, April 16, 2014 - link

    Perhaps the ideas about a notebook,or a tablet concerning the displays are somewhat different than a standalone monitor with different manufactured possibilities. That is a Hi ppi on a notebook is not 'exactly' a PNP device. It may even be moreso (not pnp) presently when graphics cards,and monitors have several different plugs available HDMI,Display Port,VGA,DVI ect. . At least more presently,the high PPI for purposes of updating applications might be considered something other than PNP - to that requiring a driver from the manufacturer. Or that would provide a foundation for its feature set.

    I say this not necesarily as a priority. But in a role model that would consist of running with the display driver,and would as well become consistant with the programming coordinates.

    The System wide DPI thing as with XP,this was one example of a the difference in application independent resolutions. The application itself,the system menus,title bars,start menus,desktop fonts as well as default texting was something wich was system wide among ALL applications.

    You also said that Apple applications are PPI aware. And that exactly takes the coding to create applications for the PPI in use.

    Then that the 'SetProcessDPIAwareness',a setting in the Windows newer application programming base is something that can do pretty much the same.

    Funny thing about VLC,is that I'm wanting to ask what file type the video was which had anything to do with the DPI.

    And with this,most of the modern day programing I'm suspecting is the standardization of,and off of the XML type 'Webbies coding. And this is a complete modernized code based from the W3C,type and formerly HTML type standards. Then those standards would be instilled to the screen programming.

    Thus not C+,C++,python etc.

    With the Adobe,the picture there,it isn't said if the screen was a 24"4K,or a 12" hi PPI screen.

    I'll wrap my comment up with what I noted at the first, is the monitors they are PNP (are they not ). Or are they just 'not exactly pnp'. There is video drivers but not a monitor driver.I'm just looking to show where you would 'map the platte',for /from .

    So where am I going ? With Windows code base as XML - the webbies. There is still the matrix of the PNP monitor. That perhaps isn't pnp- or shouldn't be. Now there are graphics drivers for other programming (Try OpenGL) . That are plenty more than just page elements.

    Windows also has some apps which is Dirx capable. That is perhaps a solution. But I suspect there is some fantastic code that needs to run independent DPI/PPI. That is requiring the metrics to do so. With whichever/whatever operating system is being used. Or what monitor is being used.

    Try running for example,a legacy 640x480 dimension ,that scales in leisure on that 4K monitor. You can of course turn on ,and turn off whichever monitor pixel you want. But look,it scales in inches. The application.

    Try running a legacy 800x600 resolution to the same. See it is the 'monitor',that is stuck in its resolution . It is somewhat might be the same,as having a virtual op.sys.run in a virtual window for a different second virtualize op.sys. .

    You can run virtualized monitors,in application space,that scales to suffice the viewing logistics.

    MOst of this article has put across the independent applications space. But not yet the independent resolution of a the application in the monitors dynamic space. And everybody needs those numbers.

    I would say the monitors must be able to use independant low resolution in dynamic space .

    Just saying.

    P.S.Thanks for the charts.
    Reply
  • Tujan - Wednesday, April 16, 2014 - link

    mean if you need 96 ppi . You have it . If you need 640x480 in 24 inches . You have x amount of dots/pionts per inch to address. Either use those pixels. Or dont use them. You may in fact have a window doing x amount of hrz. . Then another window doing a different hrz . Just to make things easier to understand . Reply
  • Pinkynator - Wednesday, April 16, 2014 - link

    I have a reasonable idea: don't invent custom DPI.

    If an old 23-24" monitor is 1920x1080 (that's 96 DPI, IIRC), a new model should be 3840x2160 (which should then be double, 192 DPI, and that's more than enough for a desktop monitor for anyone in the world not to notice individual pixels).

    Don't have a high-DPI app? Just scale assets in both dimensions by exactly 2. Your toolbar icons don't get blurry due to resizing. Fonts don't get blurry, either.

    Have a high-DPI app? Okay then, let the app give Windows its new high-res icons and let it render fonts with greater accuracy.

    Movies and games? They can render at 1920x1080 and will look exactly the same as they previously used to. No blurring because of resizing algorithms: every pixel gets quadrupled, plain and simple.

    With this "solution", everything looks just like it used to (no compatibility issues whatsoever), except when app developers explicitly decide to make things look better - and handling a straight-up 2x scale is a lot easier than today.

    "But wait!", I hear you cry, "I like my 125 DPI on this screen! It shows more of the UI!"

    Let me know how that goes in a few years, when your vision starts deteriorating due to aging, and you find even 96 DPI to be a wee bit too small.
    Reply
  • DarkXale - Wednesday, April 16, 2014 - link

    I really recommend you actually, you know, read the article? Reply
  • Pinkynator - Wednesday, April 16, 2014 - link

    I did. You didn't understand what I wrote :)

    You're not looking at the big picture. Handling DPI issues is insanely hard on legacy systems, which is why the only painless solution is to quadruple everything - based on 96 DPI. Then you get 192 DPI (or 288 DPI) "for free".

    Everything else is going to be hacks. We're still not truly in the era of high-DPI Windows machines, so there's STILL time to just unhack everything and go for easily-dealt-with multiples of 96.
    Reply
  • UsernameAlreadyExists - Wednesday, April 16, 2014 - link

    >"Handling DPI issues is insanely hard on legacy systems, which is why the only painless solution is to quadruple everything"

    And this here is the reason for the Retina display (and also the rather crazy current iPhone resolution), as the iPhone apps do not handle scaling at all. This was probably the cause for the rather low resolution with the last Symbian phones, 4x would have required 25% more pixels than iPhone 4, and would have been too expensive at the time of their release.

    However, I think going forward and just breaking things is the correct way. Winforms have their problems, but XAML makes rather many things easy. (The paradigm shift is rather big though)
    Reply

Log in

Don't have an account? Sign up now