Bringing the magic of Qt to Windows Runtime

We've been hard at work on the Windows Runtime (WinRT) port and it's about time we share a bit with all of you. For Qt 5.3, we're releasing the WinRT port as Beta quality, with most of the Qt Essentials modules in functional form (including QML & Quick). We also have preliminary tooling support, so you can get started on WinRT as quickly as you would on any other supported Qt platform.

An API for modern devices

As a reminder, Windows Runtime is a new API largely tied to Windows Store Apps, or applications which run within the Modern UI environment. It has C++ bindings (among other languages), and can be used on Windows 8, Windows Phone 8, and Windows RT - running the gamut from budget smartphones to high-end PCs. That's a lot of devices.

One of the most important things for us (and many of you) has been getting Qt Quick working smoothly on the platform. As you might guess, there are some limitations to getting such a stack working here. For one, the memory APIs which are commonly used by just-in-time (JIT) compilers (such as in QtQml's virtual machine engine) are restricted and cannot be used by apps in the Windows Store (this is, of course, for platform security reasons; the same restriction is in place on iOS). Fortunately, the V4 virtual machine which premiered in Qt 5.2 has solved this problem swimmingly, allowing WinRT to utilize the interpreted codepath for these types of operations (albeit at the cost of some less optimal code execution speed).

Qt Quick up and running

Another issue we've faced is that WinRT doesn't have a native OpenGL stack; it does, however, have Direct3D 11.1. As you might have guessed, the ANGLE project has largely solved the problem for us: Direct3D 11 support was added last year and is now in ANGLE's mainline. We've built on top of this by adding WinRT windowing types to ANGLE's EGL interface, and also made a few tweaks to support mobile GPU feature levels. The biggest hurdle, though, was finding a way to deliver pre-compiled shader binaries to our OpenGL (and Qt Quick) applications. While the traditional D3D compiler can be used on Windows 8/RT at development time, it isn't available on Windows Phone (and it isn't allowed in published apps for any WinRT target). That's right - much like the restrictions on a JIT, there's no runtime shader compiler available for Windows Store Apps. While inconvenient at times, offline shader compilation can contribute to a fluid user experience and reduced battery consumption.

Our solution has been to introduce qtd3dservice, a background process which uses an inbox/outbox approach to compiling shader source files into shader binaries at runtime. When an app needs a shader compiled, it writes the source to a directory monitored by the compilation service, and the service compiles the source and ships a binary object to the device. These blobs are cached by the service, and can be packaged into the application (e.g. in a Qt resource file) for publication. While this "just-in-time" approach to shader compilation is suboptimal for packaging (the developer must run through their app to make sure all shaders are compiled), it allows for more dynamic shader possibilities at development time. In the future, we do plan to add build-time support for shaders (such as those used internally by the Qt Quick Scene Graph), to relieve developers of this extra packaging step whenever possible.

Pick your tools

With Qt Quick working reasonably well for most apps at this stage, we are improving tooling (as Oliver has already shared, we now have a Creator plugin). The same tools which power the plugin, winrtrunner and windeployqt, can also be used from the command line. Qt Creator support, no doubt, will continue to improve as we move toward the next release of Creator, and a "one IDE" developer experience is definitely in our sights. Even so, serious debugging will still require use of Visual Studio - so, you can either use Visual Studio to complement the capabilities of Qt Creator, or simply use Visual Studio exclusively.

Going forward

Between now and the Qt 5.3.0 release, we'll keep on strengthening the stability of the port and the developer experience around it. For 5.4, we aim to improve module support, such as implementing backends for Qt Multimedia and Qt Positioning (we already have a Qt Sensors backend, though), as well as improving support for a native look and feel. Check out the Qt 5.3 Beta release, which offers binary installers for the port.

We're very excited about adding yet another platform to Qt... if you haven't gotten excited yet, perhaps a short video of the port in action will help sway you in the right direction:

Disclaimer: Parts of the video are sped up to keep the energy level high. For actual performance, please try out the port yourself :)