Qt 5 on Windows 8 and Metro UI

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

h1. Qt 5 on Windows 8 and Metro UI

1 Introduction

This document is a report on an investigation into the feasibility of supporting the Windows 8 Metro UI platform with Qt 5 and QML. It represents about ten days of investigation into the feasibility to determine if there were any showstoppers or other roadblocks and which of several approaches might be feasible. The intent is to use this preliminary investigation to make a decision on whether to proceed with the effort to support the Metro UI platform with Qt 5.

2 Project Overview

The scope of the investigation were applications written using Qt 5, specifically QML applications using the scene-graph based Quick 2 which is new in Qt 5. The target platform was Windows 8 on desktops and tablets running in the Metro UI environment. It did not look at Windows Phone 7. The current Windows Phone 7 does not support C++ programming although it appears that this will change in Windows Phone 8. The information here focuses on the x86 platform rather than ARM architecture, although most information should be applicable to both platforms.

3 Background

This section gives some background information on Windows 8 and the technical terms used in the report.

3.1 Windows 8 Versions

Windows 8 is Microsoft’s next major release of Windows, targeted at desktops, laptops, tablets, and home theatre PCs. Windows 8 will have two modes: Metro UI and Desktop. Windows 8 will target two architectures: x86 (Windows on Intel or WOI) and ARM (Windows on ARM or WOA). WOA is also known as Windows RT, not to be confused with Windows Runtime or WinRT. This diagram below shows the high-level architecture of Windows 8.

Architecture Diagram

Windows 8 is currently available as a Release Preview.

3.2 Metro UI

Windows 8 features a new user interface called Metro. The interface is suited for touch-enabled applications using a tile-based interface similar to Windows Phone. Traditional Windows desktop applications can be run on Windows 8 in desktop mode, which offers a similar interface to previous versions of Microsoft Windows.

3.3 Windows Runtime (WinRT)

Metro UI applications are developed using the new Windows Runtime platform. It supports a number of programming languages including C+, Visual Basic, C#, and HTML/JavaScript. Legacy Win32, MFC, and related APIs will only be available under the Desktop mode. To access similar services under the Metro UI mode, developers will have to use the new Windows Runtime. Native C+ development in possible in Windows 8 for both Metro UI and Desktop modes.

3.4 ANGLE

It is expected that Windows 8 Metro UI mode (i.e. WinRT) will not support OpenGL. However, Qt Quick in Qt 5 currently requires OpenGL or OpenGL ES. A possible solution is to use the open source ANGLE project [Reference 3], which translates OpenGL ES 2.0 API called to DirectX9. The problem with this is that Metro applications require the DirectX 11 SDK, which would in turn require significant porting effort to ANGLE.

3.5 Microsoft Store

Metro UI applications will be available only from the Microsoft Store. Desktop mode applications will be distributed through current means such as DVDs, downloads, etc. In addition, there will be app stores other than Microsoft’s where WOI applications can be purchased and downloaded. WOA applications will only be available through the Microsoft Store. There will be restrictions on the APIs that applications distributed in the Microsoft Store can use. For example, Microsoft had made statements that they do not want to support any Windows 7 or XP emulators of virtual machines under WOA. It is not clear if a port of Qt could be declared an emulator and forbidden under the terms of service.

4 Areas of Investigation

This section describes the investigation work that was performed.

4.1 Building Qt 5 on Windows Runtime

Before building Qt 5 under WinRT, both Qt 5 and ANGLE were built in the Win32 (desktop) environment as a point of reference.

Building ANGLE on Win32 was straightforward and proceeded with no major problems. See the Appendix for details on how it was built.

Building Qt 5 on Win32 was also completed. See the appendix for details on how it was built. In conjunction with ANGLE this allowed Qt 5 to run on Windows 8 in the desktop mode.

OpenGL rendering with ANGLE seemed to be quite functional under Win32 with no artifacts seen. The next step was to building ANGLE under the WinRT environment. Three major issues were identified here.

1. Metro-style applications are sandboxed. There is a good chance networking and file system classes will not work without modification. For example, what does file system mean in an environment which only allows an application to access storage specifically created for it?
2. WinRT uses a new ThreadPool class to handle threading. We need to figure out how this works and replace the old DLL_PROCESS_ATTACH etc. code in dllmain for both ANGLE dlls. There is a small library available which emulates the old (Win32) way of doing threading using the new Windows::System::Threading namespace in WinRT. Another possibility might be to use C++11 threading.
3. There are parts of DirectX 9 which are only available for use with Windows 8 desktop applications. Microsoft explicitly removed these capabilities, so it isn’t a valid solution to link against the old versions of the libraries. The alternative is to rewrite ANGLE to use the interfaces exposed in Metro UI applications. It is expected that the DirectX code will have to be completely rewritten using Metro UI concepts of windows and events. The code can no longer use D3DX (an entire library of deprecated convenience functions). The concept of native window handles does not exist in Metro. It is unclear if there is a solution for this last problem.

An initial effort was made to build Qt 5 on WinRT. To do this we followed the procedure that had been published for building Qt 4.8 [Reference 6]. One of the requirements was to build the Qt 5 libraries statically. We were able to build the following Qt modules/libraries on WinRT: QtConcurrent, QtCore, QtGui, QtNetwork, QtPlatformSupport, QtPrintSupport, QtQml, QtSql, QtSvg, QtTest, QtV8, QtWidgets, QtXml, QtXmlPatterns.

We were not able to build Qt Quick because of the lack of a port of ANGLE meant that there was no OpenGL support. Some “shortcuts” were needed to get Qt 5 to build, such as taking some libraries and header files from the Windows 7 SDK. These may have an impact on whether Qt could meet the Microsoft Store guidelines (See the “Risks and Unknowns” section).

4.2 Qt QPA plugin for DirectX on Windows 8

The standard approach for porting Qt 5 to a new windowing platform is to write a back end for the Qt Platform Abstraction (QPA), formerly known as Lighthouse. A QPA plugin could theoretically be written on top of DirectX for Windows 8. This would be an alternative approach to using ANGLE. However, Qt Quick 2 currently has many dependencies on OpenGL or OpenGL ES so this would involve many changes to Qt in addition to the QPA plugin. Due to the major effort to re-architect Qt Quick to remove the dependencies on OpenGL, this approach was ruled out.

4.3 QML Components for Metro UI

Qt 5 focuses on using Qt Quick (QML) and applications developed in QML for Windows 8 should support the Metro UI. Ideally a version of the Qt QML Components would be available that supports the Metro UI look and feel. This would likely need to be extended with some additional components specific to Metro UI such as Pivot and Panorama.

Some earlier work has been done to demonstrate Metro UI using QML [Reference 6]. This appears to be feasible and straightforward. Investigation of QML components for Metro UI was not part of scope of work for this initial investigation as it would be meaningless unless Qt 5 and Qt Quick can first be ported.

4.4 Microsoft Store Requirements and Restrictions

Investigating the Microsoft Store requirements and restrictions and whether Qt on Windows 8 will meet the terms of service is an area that requires additional work once more is known about the store requirements. This was not part of the scope of this initial investigation work.

5 Risks and Unknowns

The following are areas of risks and unknowns that require further investigation if the project moves forward to an implementation phase:

1. It will be a significant effort to port ANGLE to WinRT. It is unclear if this will even be possible due to the limitations of WinRT (specifically, the lack of native window handles). It will almost certainly require changing all DirectX 9 calls to equivelent DirectX 11 calls (see porting guide). Even if this is possible, there is a risk that ANGLE-based Qt Quick applications would be ineligible for the Microsoft Store unless full binary shader support can be added to Qt/QML. See this link, which suggests that dynamically compiling and linking shaders (something used heavily within the SceneGraph and required by e.g. the QML ShaderEffect), is only available during development; developers are required to provide object code for all shader binaries used within store applications.

1. WinRT imposes some restrictions on file system and networking access. These need to be investigated in more detail to determine if they will affect the ability to implement some of the Qt APIs in these areas.
2. Some Windows 7 DLLs were needed to get Qt 5 to compile and link. More investigation is needed to determine if these DLLs will exist on Window 8, or if not, whether using them will violate the terms of service for applications distributed in the Microsoft Store.
3. Investigation focused on the Intel architecture. There may be additional issues specific to Windows 8 on ARM.
4. Windows 8 is not yet released so the supported APIs are still subject to change.

6 Effort Estimates

The following are some very rough order of magnitude estimates of possible future work.

Port ANGLE to WinRT: Unknown until more investigation is done. We estimate at least 10 to 15 man-days of further research is needed to determine if ANGLE on WinRT is feasible. If investigation finds that this is feasible, the effort is expected to be significant.

Port Qt 5 to WinRT: effort will vary depending on how many modules are ported, the assumption is just the Essential modules for now (Having seen that Windows 7 dlls cannot be used, some major rewrite has to happen to do a proper Qt port. Thus it is hard to tell, how much time will be needed)

Implement Metro UI version of Qt Quick Components: 150 man-days including testing, documentation, and writing at least one demonstration application. The effort would be more if additional components specific to Metro UI are developed.

Investigate Microsoft Store requirements: 20 man-days (includes writing a document on how to make Qt applications compliant).

It is likely that the Qt 5 effort can leverage work already being done to port Qt 4 to WinRT and also leverage Digia's work on a QML-based Metro UI for Qt 4. If so, the effort could likely be reduced.

7 Conclusions

Based on this initial investigation, the only technical roadblock to supporting Qt 5 on Windows 8 and Metro UI is the effort to port ANGLE to WinRT. More research is needed to determine if this is feasible and what the effort would be. Other approaches, such as those not based on ANGLE and using DirectX only, do not appear feasible.

Note that running Qt desktop applications on Windows 8 using Win32 and desktop mode can be done today with no development effort. However, the goal here was for Metro UI applications using QML and Qt 5. Further work is needed to investigation the Microsoft Store requirements, the effort to develop Metro UI versions of the Qt Quick Components.

8 References

1. Windows 8 Release Preview
2. Visual Studio 2012 Release Candidate
3. Angle Project
4. Building Qt 5 with support for Angle
5. Metro UI look and feel using Qt 4 and QML
6. Prototype Qt 4 code on Windows 8 with Metro UI
7. Qt 4 port to Windows 8 / Windows Runtime

A Appendix

A.1 Notes on Building ANGLE on Windows 8 Win32

ANGLE builds “out of the box” on Windows 8 using Visual Express 2008 as documented in the build instructions on the ANGLE project Wiki . It did not build using Visual Studio Express 2012 Release Candidate but it did build with Visual Studio Professional 20112 Release Candidate.

A.2 Notes on Building Qt 5 on Windows 8 Win32

Building Qt 5 on Windows 8 Win32 works just fine using the instructions on the Building Qt 5 Wiki page [Reference 4]. Note that when building with ANGLE, you need to use the “opengl es2 -angle“ options, as suggested on the site.

A few errors were encountered during the build. A compile error in $(QtDir)3d\src\threed\textures\qgltextureutils.cpp about coercing types was fixed by adding a dynamic_cast to the specified type. One of the OpenGL examples complained about missing identifiers (e.g. glVertex3f, glBegin, glEnd). These should not exist in an OpenGL ES 2.0 application as those identifiers were relics from fixed function OpenGL, which was removed in ES 2.0, so it is a problem with this particular example application.

I then tested various demos and examples, including qmlscene. But first, I wanted to verify that ANGLE was really being used. So I introduced a failure into the ANGLE GLES2 Context API (ASSERT (0==1)). The applications failed as expected. I also tested with both the Debug and Release builds of Angle. Both worked fine, although Debug builds were much slower than the Release builds using a basic example hellowindow. With the Debug build, approximately 40% CPU usage was seen. With Release, it was about 2%. I guess this is not unexpected.

After the hellowindow test, I stuck with the Release build of Angle for testing other examples. I ran through most of the OpenGL examples in qtbase. I saw no issues, rendering artifacts or any instability.

Using qmlscene, I ran several of the example qml’s such as clocks, plasmapatrol, samegame, rssnews, minesweeper, rssnews and several others. There were a couple of QML apps that did have problems, such as snake. This app (and a couple of others) caused an EGL error 3003 (EGL_BAD_ALLOC) during surface creation. It is not clear why this error occurred- more investigation will be required. It may be that the graphics hardware I am using cannot support whatever surface attributes the application needed. It was an older card.

In testing Angle with Qt5, on Win32 I found it to be quite reliable and saw no rendering artifacts. Investigating the reason for the EGL_BAD_ALLOC failures with some apps might be worthwhile in the future. EGL_BAD_ALLOC is one of those ‘generic’ errors that can have many possible causes.

h3. A.3 Notes on Building ANGLE on Windows 8 WinRT

You must define WINAPI_FAMILY WINAPI_PARTITION_APP in order to allow a Win32 DLL to be used in a MetroUI application. This has some consequences:

• Metro-Style applications are sandboxed. There is a good chance networking and file system classes will not work without modification

• WinRT uses a new ThreadPool class to handle threading. Need to figure out how this works and replace the old DLL_PROCESS_ATTACH etc. code in dllmain for both ANGLE dlls. There is a ”small library[http://blogs.msdn.com/b/shawnhar/archive/2012/03/12/createthread-for-windows-8-metro.aspx . It did not build using Visual Studio Express 2012 Release Candidate but it did build with Visual Studio Professional 20112 Release Candidate.

A.2 Notes on Building Qt 5 on Windows 8 Win32

Building Qt 5 on Windows 8 Win32 works just fine using the instructions on the Building Qt 5 Wiki page [Reference 4]. Note that when building with ANGLE, you need to use the “opengl es2 -angle“ options, as suggested on the site.

A few errors were encountered during the build. A compile error in $(QtDir)3d\src\threed\textures\qgltextureutils.cpp about coercing types was fixed by adding a dynamic_cast to the specified type. One of the OpenGL examples complained about missing identifiers (e.g. glVertex3f, glBegin, glEnd). These should not exist in an OpenGL ES 2.0 application as those identifiers were relics from fixed function OpenGL, which was removed in ES 2.0, so it is a problem with this particular example application.

I then tested various demos and examples, including qmlscene. But first, I wanted to verify that ANGLE was really being used. So I introduced a failure into the ANGLE GLES2 Context API (ASSERT (0==1)). The applications failed as expected. I also tested with both the Debug and Release builds of Angle. Both worked fine, although Debug builds were much slower than the Release builds using a basic example hellowindow. With the Debug build, approximately 40% CPU usage was seen. With Release, it was about 2%. I guess this is not unexpected.

After the hellowindow test, I stuck with the Release build of Angle for testing other examples. I ran through most of the OpenGL examples in qtbase. I saw no issues, rendering artifacts or any instability.

Using qmlscene, I ran several of the example qml’s such as clocks, plasmapatrol, samegame, rssnews, minesweeper, rssnews and several others. There were a couple of QML apps that did have problems, such as snake. This app (and a couple of others) caused an EGL error 3003 (EGL_BAD_ALLOC) during surface creation. It is not clear why this error occurred- more investigation will be required. It may be that the graphics hardware I am using cannot support whatever surface attributes the application needed. It was an older card.

In testing Angle with Qt5, on Win32 I found it to be quite reliable and saw no rendering artifacts. Investigating the reason for the EGL_BAD_ALLOC failures with some apps might be worthwhile in the future. EGL_BAD_ALLOC is one of those ‘generic’ errors that can have many possible causes.

h3. A.3 Notes on Building ANGLE on Windows 8 WinRT

You must define WINAPI_FAMILY WINAPI_PARTITION_APP in order to allow a Win32 DLL to be used in a MetroUI application. This has some consequences:

• Metro-Style applications are sandboxed. There is a good chance networking and file system classes will not work without modification

• WinRT uses a new ThreadPool class to handle threading. Need to figure out how this works and replace the old DLL_PROCESS_ATTACH etc. code in dllmain for both ANGLE dlls. There is a ”small library] written by someone which emulates the old (Win32) way of doing threading using the new Windows::System::Threading namespace in WinRT.

• There are parts of DirectX 9 which are only available for use with Windows 8 desktop applications. Microsoft explicitly removed these capabilities, so it isn’t a valid solution to link against the old versions of the libraries. The alternative is to rewrite ANGLE to use the interfaces exposed in MetroUI applications.

The DirectX code will have to be completely re-written using MetroUI concepts of windows and events.

To build ANGLE on WinRT (MetroUI on Windows 8):

1. Install Windows 8 Release Preview SDK.
2. Windows 8 SDK now contains DirectX SDK.
3. Install Visual Studio 2012 Release Candidate.
4. Error: Dependency on d3dx9. All D3DX has been removed from Win8/DirectX. Follow instructions here to compile/link for legacy apps using d3dx.

A.4 Notes on Building Qt 5 on Windows 8 WinRT

Qt was built on WinRT (MetroUI and no ANGLE). It should be noted this was done in part to confirm Qt 5.0 will not build without ANGLE / OpenGL libraries. It was built as follows:

1. Using this as a guide to get started building Qt.
2. Download Windows 7 SDK to include legacy Windows Libraries and Headers
3. Configure per instructions on the Qt 4.8 on Metro wiki (with below deviations):
4. included -nomake tests
5. some tests failed to compile
6. Used Visual Studio 2012 RC Professional