Bringing the magic of Qt to Windows Runtime

Published Tuesday March 25th, 2014 | by

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.

SameGame on WinRTQt Quick Same Game running on Windows RT 8.1 (Microsoft Surface RT) and Windows Phone 8 (Nokia Lumia 920)

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:

Various Qt demos running on Windows 8.1, Windows RT, and Windows Phone 8

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

Did you like this? Share it:
Bookmark and Share

Posted in cross-platform, integration, OpenGL, QPA, Qt Quick 2, Windows, WinRT

18 comments to Bringing the magic of Qt to Windows Runtime

Benoit says:

Impressive work, congratulation! BlackBerry 10, iOS, Android, Sailfish AND Windows…

m][sko says:

What about debugging on windows phone emulator/device?
Are you planning to support this feature in QT 5.3 final ?

Andrew Knight says:

No, unfortunately debugging for the Phone/Emulator is only possible via Visual Studio at the moment. We intend to enable debugging for local WinRT apps in Creator 3.1 final.

m][sko says:

Any reason for this?

And how can I use d3dshader service with windows phone emulator/device
As now when I build and start qml application(for example from qt creator wizzard). Application is in state “starting….” as it looks like I don’t have shaders ready.

Andrew Knight says:

Creator doesn’t yet have support for the debugger (msvsmon) used by Windows Phone. We traditionally use CDB on Windows/MSVC, which also works for local WinRT apps but is not available on the phone.

Please visit http://qt-project.org/wiki/qtd3dservice for info about the shader service. There is a shortcut installed with the Beta packages which will run the service in a console window.

m][sko says:

WinRT modern UI application
And I get this from application output
http://pastebin.com/Nv0ZqgrU

application directory
http://pastebin.com/imPh3vZ7

WinPhone app stop in starting state I don’t see any errors, but we don’t have application output.

Any idea?
It is application from qt creator wizzard.

I think you should notice that We will need to enable WinRT plugin in qt creator in qt5.3 beta

Andrew Knight says:

Yes, you will need to manually enable the WinRT plugin in Qt Creator. This is (hopefully) getting fixed for the final release.

The error you are seeing is caused by a bug in the Creator plugin, but unfortunately it got fixed after the 3.1 Beta release. You may work around this by unchecking the “Shadow Build” box in Creator.

m][sko says:

sorry
it is Qt Quick Application from qtcreator wizzard

Maurice Kalinowski says:

Alternatively you can also disable shadow build for the project.

The reason why it fails is that it called windeployqt with the wrong working directory. However, that is fixed in latest Qt Creator build and will be fixed in 5.3RC.

m][sko says:

Thx
WinRT modern app started fine now :)
but
And what about WinPhone
I started qtd3dservice and application in emulator

still in starting state

and this is log rom qt3dservice
http://pastebin.com/LGTLuvEf

application directory
http://pastebin.com/08EwSLvM

btw
Did you guys pre-build some shaders in dlls ?
As I check qtd3dservice directory and I didn’t found any precompiled shaders for winrt or winphone app.
And sometimes I get this:

qt.d3dservice: Unable to create the shader source directory: “The system cannotfind the path specified.”

Andrew Knight says:

Please run the WP project from Visual Studio to get debug output. The warnings from the shader service are normal when reinstalling the app (maybe we should make it a bit less noisy :) ).

The only pre-built shaders currently are those used by the backing store (so widgets/raster apps don’t need qtd3dservice) and ANGLE itself.

m][sko says:

It looks like Visual Studio Add-in 1.2.3 Alpha don’t support winrt qt5 sdk
But desktop sdk works fine

Are there any newer version with winrt support?
I get this error when I add winrt qt5 sdk to VS addon
Illegal character in path

Andrew Knight says:

The Visual Studio Add-in is not required. Simply generate your project and open it in VS:
path\to\Qt\bin\qmake -tp vc CONFIG+=windeployqt path\to\project

You can then regenerate this each time your .pro file changes. You can edit in QtC, but deploy/debug from VS.

You may find related info at http://doc-snapshot.qt-project.org/qt5-stable/winrt-support.html

m][sko says:

Now it works thx
http://pastebin.com/wAZuGiTK
except we miss fonts in package :)

It is really interested that WinRT provide some fonts and phone don’t

Are you planning to add qt creator deployment?

I think you should update WinRT blog post with more informations about deployment.

Andrew Knight says:

This is because WinRT supports DirectWrite and Windows Phone doesn’t – hopefully the situation improves in WP 8.1. We have already added an automated step (it didn’t make the Beta, though) which adds a few default fonts to the Windows Phone package.

We plan to publish a “getting started” post (complete with deployment instructions) closer to the 5.3 final release.

Thanks for the useful feedback, though, and good to see that you’ve been able to get started :)

rahul says:

About shader compiler, afaik in Windows 8.1 the runtime shader compiler is now available to WinRT apps. For example, D3DCompile is now available to Store apps. Only a few functions (eg: D3DCompileFromFile) are excluded but in general you can now compile shaders at runtime.

Andrew Knight says:

Thanks for pointing this out! The shader service is indeed optional on Windows 8.1/RT. You may still use it for debugging and/or performance benefits, though.

We do have a few adjustments in this area to make before 5.3 final, because currently the d3dcompiler is packaged with the app and dynamically loaded. It should be directly linked instead, something we’ll make sure to take care of before the RC.

erdem says:

Many thanks for this great job. Keep up wonderful work Qt team…

Commenting closed.