Future-Proofing Desktop Applications for Hardware Enhancements

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.

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.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.