Though CPUs aren’t getting any faster, other hardware capabilities are rapidly increasing. Future proofing for better higher DPI and new input devices is essential.
High DPI Devices
With higher and higher resolution displays becoming available, scaling is starting to become a major concern. With Windows 8, scaling was available up to 150%. Windows 8.1 bumped that up to 200% and the soon to be released Win 8.1 Update will further push that to 250%. But that’s only for high-end machines, mainstream machines are only expected to need 150% scaling in 2015.
A major problem with scaling bugs is that developers often don’t have access to these high resolution screens. And even if they do today, they won’t have access to next year’s hardware. This problem is compounded for enterprise developers who tend to develop applications that need to work largely unaltered for five to ten years on a wide range of hardware.
Microsoft’s plan to work around this is to leverage Remote Desktop. By setting the scaling at values from 100% to 500%, developers can see how their application behaves without a high DPI monitor. It isn’t an ideal experience, as the screen is zoomed in to potentially absurd levels. A whitepaper on how to enable this will be published sometime next month.
In order to actually deal with scaling bugs, Microsoft recommends a few techniques. One is to favor vector based assets over fixed assets. Generally speaking, vectors are going to scale much better than bitmaps. Overlaying actual fonts instead of pictures of text can also be useful.
Docking can be a serious challenge to developers. As the application moves from a low DPI laptop or tablet display to a high TPI monitor. Applications may even need to rescale as individual windows are moved from one monitor to the next.
Desktop “Win32” applications are the most problematic for scaling because there is no framework support for it; the applications need to scale themselves. So Microsoft recommends using XAML-based technologies such as WPF or WinRT instead.
For more information on scaling in WPF, see Developing a Per-Monitor DPI-Aware WPF Application.
Input Devices
In the past there was just keyboard and mouse. Then pens were added, followed by touch screens and gestures. In the future common applications may even be expected to support Kinect. Writing code that handles all these requires rethinking how applications listen to events.
For new applications recommends that all applications (WPF, WinRT, and HTML5) rely on the pointer API instead of the mouse API. The pointer API simplifies development by unifying mouse and touch events into a single event pipeline that the application. For desktop applications the unified pipeline is opt-in via EnableMouseInPointer. This was necessary to for backwards compatibility in misbehaving applications.
For simple C++ applications changing to pointer events requires minor changes. Handlers for pointer messages (i.e. WM_POINTERDOWN) need to be used instead of the matching mouse messages. Also note that pointer messages use screen coordinates while mouse messages use client coordinates. Fortunately there are systems functions that can do the conversion for you.
We mentioned that Kinect might need to be supported. How that support will happen for common applications is not yet known. They may eventually include it into the pointer API, but as it stands you have to use the Kinect Windows SDK directly.
