 | ||
Resolution independence is where elements on a computer screen are rendered at sizes independent from the pixel grid, resulting in a graphical user interface that is displayed at a consistent size, regardless of the size of the screen.
Contents
Concept
As early as 1978, the typesetting system TeX due to Donald Knuth introduced resolution independence into the world of computers. The intended view can be rendered beyond the atomic resolution without any artifacts, and the automatic typesetting decisions are guaranteed to be identical on any computer up to an error less than the diameter of an atom. This pioneering system has a corresponding font system, Metafont, which provides suitable fonts of the same high standards of resolution independence.
The terminology device independent file format (DVI) is the file format of Donald Knuth's pioneering TeX system. The content of such a file can be interpreted at any resolution without any artifacts, even at very high resolutions not currently in use.
OS X
Apple included some support for resolution independence in early versions of OS X (formerly Mac OS X), which could be demonstrated with the developer tool Quartz Debug that included a feature allowing the user to scale the interface. However, the feature was incomplete, as some icons did not show (such as in System Preferences), user interface elements were displayed at odd positions and certain bitmap GUI elements were not scaled smoothly. Because the scaling feature was never completed, OS X's user interface remained resolution-dependent.
On June 11, 2012, Apple introduced the 2012 MacBook Pro with a resolution of 2880×1800 or 5.2 megapixels - doubling the pixel density in both dimensions. The laptop shipped with a version of OS X that provided support to scale the user interface twice as big as it has been previously been. This feature is called HighDPI mode in OS X and it uses a fixed scaling factor of 2 to increase the size of the user interface for high-DPI screens. Apple also introduced support for scaling the UI by rendering the user interface on higher or smaller resolution that the laptop's built-in native resolution and scaling the output to the laptop screen. One obvious downside of this approach is either a decreased performance on rendering the UI on a higher than native resolution or increased blurriness when rendering lower than native resolution. Thus, while the OS X's user interface can be scaled using this approach, the UI itself is not resolution-independent.
Microsoft Windows
The GDI system in Windows is pixel-based and thus not resolution-independent. To scale up the UI, Microsoft Windows has supported specifying a custom DPI from the Control Panel since Windows 95. (In Windows 3.1, the DPI setting is tied to the screen resolution, depending on the driver information file.) When a custom system DPI is specified, the built-in UI in the operating system scales up. Windows also includes APIs for application developers to design applications that will scale properly.
GDI+ in Windows XP adds resolution-independent text rendering however, the UI in Windows versions up to Windows XP is not completely high-DPI aware as displays with very high resolutions and high pixel densities were not available in that time frame. Windows Vista and Windows 7 scale better at higher DPIs.
Windows Vista also adds support for programs to declare themselves to the OS that they are high-DPI aware via a manifest file or using an API. For programs that do not declare themselves as DPI-aware, Windows Vista supports a compatibility feature called DPI virtualization so system metrics and UI elements are presented to applications as if they are running at 96 DPI and the Desktop Window Manager then scales the resulting application window to match the DPI setting. Windows Vista retains the Windows XP style scaling option which when enabled turns off DPI virtualization (blurry text) for all applications globally.
Windows Vista also introduces Windows Presentation Foundation. WPF applications are vector-based, not pixel-based and are designed to be resolution-independent.
Windows 7 adds the ability to change the DPI by doing only a log off, not a full reboot and makes it a per-user setting. Additionally, Windows 7 reads the monitor DPI from the EDID and automatically sets the DPI value to match the monitor's physical pixel density, unless the effective resolution is less than 1024 x 768.
In Windows 8, only the DPI scaling percentage is shown in the DPI changing dialog and the display of the raw DPI value has been removed. In Windows 8.1, the global setting to disable DPI virtualization (only use XP-style scaling) is removed. At pixel densities higher than 120 PPI (125%), DPI virtualization is enabled for all applications without a DPI aware flag (manifest) set inside the EXE. Windows 8.1 retains a per-application option to disable DPI virtualization of an app. Windows 8.1 also adds the ability for each display to use an independent DPI setting, although it calculates this automatically for each display. Windows 8.1 prevents a user from forcibly enabling DPI virtualization of an application. Therefore, if an application wrongly claims to be DPI-aware, it looks awful at high-DPI displays in 8.1, and a user cannot correct that.
Windows 10 adds manual control over DPI for individual monitors.
Android
Since Android 1.6 (Donut, September 2009) Android has provided support for multiple screen sizes and densities. Android expresses layout dimensions and position via the density-independent pixel or "dp" which is defined as one physical pixel on a 160 dpi screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use.
To aid in the creation of underlying bitmaps, Android categorizes resources based on screen size and density:
Linux desktop environments
In 2013, the GNOME desktop environment began efforts to bring resolution independence ("hi-DPI" support) for various parts of the graphics stack. Developer Alexander Larsson initially wrote about changes required in GTK+, Cairo, Wayland and the GNOME themes. At the end of the BoF sessions at GUADEC 2013, GTK+ developer Matthias Clasen mentioned that hi-DPI support would be "pretty complete" in GTK 3.10 once work on Cairo would be completed. As of January 2014, hi-DPI support for Clutter and GNOME Shell is ongoing work.
Other
Although not related to true resolution independence, some other operating systems use GUIs that are able to adapt to changed font sizes. Microsoft Windows 95 onwards used the Marlett TrueType font in order to scale some window controls (close, maximize, minimize, resize handles) to arbitrary sizes. AmigaOS from version 2.04 (1991) was able to adapt its window controls to any font size.
Video games are often resolution-independent; an early example is Another World for DOS, which used polygons to draw its 2D content and was later remade using the same polygons at a much higher resolution. 3D games are resolution-independent since the perspective is calculated every frame and so it can vary its resolution.