High DPI monitors are becoming more and more common. 4K or 5K monitors in 24” or 27” form factors have pixels too small to run them at their native resolution (unless you have super-vision) and so these will most commonly be used at higher DPI scaling levels (e.g. instead of the 96 dots-per-inch on a standard monitor, they may be run at 125% (120 dpi), 150% (144 dpi), 200% (192 dpi) or even higher). This lets text and icons be sharper and clearer, but without providing any more “usable” screen space.
In practical terms what this means is that software GUIs have to either be up-scaled by the OS (resulting in a blurry or fuzzy appearance of things like text and icons), or support higher DPI natively with higher resolution icon imagery.
Opus 12 configurations store the DPI setting along with your configured font sizes, which means you can move your configuration between different DPIs (say, a high-DPI desktop and a low-DPI laptop) and the correct font size will be used. In Opus 11 this would result in your fonts being either too big or too small, depending on the machine the configuration was saved on.
The first time you use an earlier configuration with Opus 12, your existing font sizes will be reset to the defaults.
Toolbar icon sets have always supported two icon sizes (small and large); that is, an icon set could contain two completely different sets of images that were used for icons at the two sizes. In Opus 12 icon sets still support two “named” sizes (small and large), but each size can have more than one set of image data, flagged for differing DPI levels. Each set of images can be given a maximum and minimum DPI scaling level that it’s designed for, and Opus will pick the most appropriate size to use automatically.
If an icon set doesn’t have images designed for the current DPI level, Opus will pick the closest size and automatically scale it up (or down) so that all toolbar icons are displayed with the correct dimensions.
Elements with configurable widths (status bar parts, status bar graphs, and the breadcrumbs path field) are now scaled for the system DPI by default. E.g. a status bar part set to width 200 (with the {width200} code) will be 400 pixels wide on a system with 200% DPI scaling.
If you specifically want an absolute width that doesn’t get scaled, simply specify a negative number instead. For example, a status bar part set to {width-200} would be 200 pixels wide no matter what the DPI scale factor.
The new {dpi} command argument lets you use DPI-sensitive values with simple commands. This can be useful if you have buttons which specify column or window sizes and you want consistent results from the same button in different DPIs.
{dpi} on its own will report the current DPI. 96 at standard DPI, 192 at 200% DPI, and so on.
{dpi|%} will report the current DPI scale factor. 100 at standard DPI, 200 at 200% DPI, and so on.
{dpi|<number>} converts a standard 96 DPI pixel width to the current DPI. For example, if you are at 200% DPI, {dpi|25} will output 50.
{dpi|/<number>} will convert from the current DPI back to standard 96 DPI pixels. For example, if you are at 200% DPI, {dpi|/50} will output 25.
Example use in a command: Set LISTERSIZE {dpi|640},{dpi|480}. For scripts, the new DPI object (obtained via the DOpus.DPI method) provides similar functionality.