The official source of product insight from the Visual Studio Engineering Team
Visual Studio has had support for High-DPI modes for some time. Visual Studio 2010 adopted WPF as its primary UI framework, which addressed many existing high-DPI issues. Some of our components which leverage Win32, however, had not been fully updated to incorporate high-DPI awareness. At the beginning of 2013, Microsoft shipped the Surface Pro which supported 210 pixels per inch and with a default DPI scaling of 150%. Later that year, 4k resolution displays debuted at CES in Las Vegas. We committed to making sure we were ready for these devices.
New, high-resolution displays improve the quality in rendering of our user interface. Text in particular gets crisper by rendering using more pixels. For example
11 point text at 100% DPI Scaling:
11 point text at 200% DPI scaling:
In planning for Visual Studio 2013 we considered what it would take to enable great high-DPI support for Visual Studio. There is an article on MSDN that describes some of the types of issues we would run into. We gathered hardware and found and fixed critical bugs that we saw by running Visual Studio on multiple resolutions and DPI scaling factors. We knew we needed to build a way to ensure consistency across the Visual Studio product and its extensions.
To kick the process off, we tested Visual Studio at high-DPI. The first thing we realized was that we needed to use actual high-DPI hardware. We tried using a typical 110DPI display (27” desktop monitor at 25060 x 1440) with scaling at 150% didn’t achieve the right result. At first, we actually overlooked critical issues at first such as tiny icons or narrow clickable regions that didn’t seem such a big deal because the size of the hardware made interaction and viewing distance issues less obvious. Having teams use the actual hardware made the impact of issues much more apparent. To help things further, we had some people use Visual Studio on the actual hardware as a part of their daily work. My laptop was definitely the subject of some gear envy around the office.
The top issues we found in Visual Studio fell into three categories:
Our biggest category of issues revolved around images that were just too small. Visual Studio has over 10,000 images (mostly 16x16 pixel icons) that need to be drawn to the proper size. Many of these images need to be clicked on, so leaving an icon at 16x16 when the rest of the UI was scaled up was not acceptable – the images needed to scale up too. We decided to scale icons at runtime and make them consistent across the product.
We had to work with several UI technologies to get the balance right and consistent for the product. By default, WPF uses a bi-cubic scaling algorithm for scaling images, which can have a fuzzy effect when scaled up. By contrast, many of Win32-based graphics components can automatically scale images using a naïve nearest neighbor algorithm, which can look blocky and pixilated. Since Visual Studio uses Win32, WPF and HTML based UI, we made changes to make the algorithm consistent across all technologies.
The biggest part of the work was to get all images in Visual Studio to load and render the same way. As a part of centralizing dealing with these images, we created some code that decides what image scaling algorithm to use so that we could make consistent decisions about the look of all images. This enabled us to make tough calls about the experience for the whole product. For example, when an image is rendered with 200% DPI scaling, we determined naïve nearest neighbor was the best-looking algorithm by looking at how it worked for whole entire product. In addition, we also determined bi-cubic scaling did the best job to ensure the sizing and readability at 125 and 150. We even had the freedom to try some more radical approaches like centering the image on a placeholder of the right size and while it preserved crispness, however it made the icon harder to “read” at the normal viewing distance for the high-density displays even at 125 and 150% scaling.
In the end, we chose the following algorithms to display our images the Visual Studio:
As a result of the work done by all our teams, Visual Studio 2013 contains much improved support for high-DPI. Text is now consistent and crisp, layout is much improved, and the application needs little forgiveness when dealing with high-DPI.
Visual Studio 2013 at 100% scaling:
Visual Studio 2013 at 150% scaling:
Visual Studio 2013 at 200% scaling:
I think we dramatically raised the quality of the experience on high-density displays in Visual Studio 2013, but we still have more to do. For example, we need to update our extensibility model to enable it to accept high-resolution images based on the display setting in the future.
We’d love it if you would help us prioritize this work. Please leave blog comments and log Connect bugs to help us make this work for you on the exciting new devices.
Art Leonard – Development Lead, Visual Studio
Art started at Microsoft in 1998 and joined the Visual Studio team in 2007. His team is responsible for the basic functionality behind Visual Studio’s user experience, window system, and extensibility.