Status Update on Qt for WinRT / UWP

It has been a long while since we were writing on this blog about the WinRT port of Qt.

Hence, this is going to be a longer article on what we achieved in the meanwhile, are currently working on, and what we will provide in future releases.

Supported Platforms

WinRT as a platform API set has been continuously improved and new features have been added which Qt can make use of, allowing us to provide more of Qt API to developers. One example is drag and drop support.

Many of you might have heard of the terminology Universal Windows Platform, or UWP. This describes a rather high level abstraction, in the end it boils down to the WinRT API being used and extended. Hence, the Qt for WinRT version currently supports the following platforms:

• Windows 8.1
• Windows Phone 8.1
• Windows 10
• Windows 10 Mobile
• Windows 10 IoT (Core/Professional) *
• Microsoft Hololens *
• XBOX One *

* I will talk about those platforms later.

Previous / Current Qt releases

Qt 5.6 marked an important release for the port as we needed to exchange a lot of the internals to be able to integrate custom Xaml content into a Qt application. One example of achieving this was to enable support for Qt WebView, which integrates Microsoft Edge into a Qt application. In case you have your own custom Xaml content you need integrated, I recommend to take a look at the source code. You will recognize that there are some caveats on what you need to do from which thread.

Furthermore, we have been working a lot on camera support in Qt Multimedia, added synthesis of Pen events to use it e.g. on Surface devices and general bug fixes and stability improvements. At Qt 5.6 is a LTS release, we will also continue to update this branch and provide fixes for crucial bug reports.

In addition Qt 5.6.1 includes two workflow changes I would like to highlight:

1. Creating a Visual Studio project with qmake does not require to add CONFIG+=windeployqt anymore. We have recognized that almost all users use this option instead of manually deploying or collection libraries and plugins for the package. Hence, we enabled it by default.
2. We added a default capability feature for the template manifest. As an example, if you use QT+=multimedia in your project, this will automatically add webcam and microphone capabilities to your project. The benefit is that during development you will have all features available without considering which capability matches which feature. However, you have to make sure to remove non required capabilities during the publishing process. For instance, the internetClientServer capability is enabled by default allowing an app to act as a server. In most cases you will not need this capability for your app.

Moving on to Qt 5.7 there are two features to emphasize about Qt on WinRT.

First of all, we added a low latency audio plugin, utilizing WASAPI. This was due to huge request by users. Additionally, this plugin can also be used for classic development, meaning regular desktop applications. The advantage against the windowsaudio backend using WaveOut is clearly found in latency. According to Microsoft the guaranteed latency has been greatly reduced in Windows 10 and later releases and you will be able to utilize it with Qt plugin. The downside is that WASAPI synchronizes the sample-rate to the audio driver without providing any conversion capabilities for a developer. Hence, you are responsible for converting between sample rates in case those do not match. The plugin is not enabled by default for the desktop platforms, but you can compile, test and use it from our git repository or source package.

One additional item we have added with experimental support is to use JIT in the QmlEngine on x86 and x64 architectures. You might remember that initially this was not supported for the Windows Store. However, this seems to have changed even though there is no public statement or documentation about this yet. Using JIT can speed up your application significantly depending on your use cases, for instance some test functions in the engine auto tests executed faster by a factor of 100+. To enable this in your WinRT app, all you have to do is add the codeGeneration capability in your manifest, recompile your appx and start testing. From our experiments it is possible to push and publish an app in the Windows Store, however it is not guaranteed that this feature will stay. We have been told that this capability is mostly used for .NET native, but also (or because of it) allows VirtualAllocFromApp/VirtualFree to succeed.

Future Qt releases

We would like to see JIT also available on ARM to use it for on mobile platforms and also Windows 10 IoT Core, where speed improvements are even more crucial. Unfortunately, the current public API does not provide us everything we need, for instance flushing cache lines is not supported. Once those items are public, we can continue on topic and we will keep you updated. You can also watch the WIP in the meanwhile.

Qt 5.8 is already shaping up with feature freeze approaching in less than a month. Hence I would like to summarize a couple of items we have been working on for this release.

Again, we validated the reports for WinRT with the highest votes to get an understanding what is most important for users and customers. From that list Qt 5.8 will add support for BTLE and Qt Purchasing to publish applications in the Windows Store using In App Products.

Qt Speech will be part of Qt 5.8 as a tech preview module, including support for WinRT using the Speech Synthesizer API.

Lastly, you might have read about our efforts to decouple the hard dependency of Qt Quick on OpenGL and providing additional backends. Laszlo has been doing an incredible job adding a D3D12 backend, which will also work for WinRT. For more information, you can read the snapshot documentation.

Platform Ammendment

Windows 10 IoT Core / Professional

Microsoft has introduced a new line of embedded operating systems called Windows 10 IoT. This is based on the Windows 10 architecture and comes with a limited feature set tailored towards embedded use-cases. For instance, no window manager / compositor is supported, only one application is supposed to show full screen. There are images available for various embedded devices, like the Raspberry Pi or the Dragonboard 410c, but the user experience might vary heavily depending on the snapshot of the image and its driver status. There is no graphics acceleration for the Raspberry Pi, causing Qt for WinRT to use the WARP software renderer with fairly bad fps rendering and a broken user experience. The Dragonboard has graphics acceleration and visually it is way more appealing, but you might experience troubles in other areas.

Microsoft Hololens

Unfortunately, we did not have the chance yet to experiment with the Hololens physically. But there are emulator images available and according from our experience using those, Qt does run on the Hololens. When publishing your app to the Store you can select the Hololens as an additional target to deploy to. In case you have experience with Qt on this device, feel free to get in touch with us.

XBOX One

The XBOX One will be opened towards 3^rd party developers in one of its upcoming releases. Developers are already capable of setting the console into development mode and start coding on it. Using Qt for WinRT you will be able to develop Qt applications for the XBOX One and, once enabled, push those to the Store. From our experience input handling is not working to our fullest satisfaction, but we will work on this in the nearer future.

Moving further into the future there a lot of items we would like to do for the WinRT port, but we also need your feedback on what is important for developers. Hence I would like to ask every developer on this platform to vote and/or create items on our bugtracker. For easier tracking, all WinRT related items have QtPorts:WinRT as component.