Details
-
Technical task
-
Resolution: Done
-
P2: Important
-
None
-
-
752497910b67b2a1a80560840ca44548d8893434 (qt/qtbase/dev)
Description
Qt 6.0 is expected to ship without ANGLE as a 3rd party dependency. This does not just involve removing ANGLE itself from the source tree, but we also need to consider what to do with things like:
- the EGL plumbing (QWindowsEGLContext and related stuff) in the windows platform plugin
- This is quite important because once ANGLE is disconnected from the build, the platform plugin simply won't build due its dependency on EGL in QWindowsEGLContext (and maybe a few other places)
- A decision needs to be made if losing ANGLE support for ever is acceptable or not. Not shipping ANGLE with Qt is one thing, but allowing applications to provide their own ANGLE build is another. (however due to the lack of compatibility promises from external projects this probably cannot be guaranteed)
- the related bits in the OpenGL detection and the (device ID and driver version based) blacklisting machinery on Windows,
- any related documentation and tooling (windeployqt, for example),
- build and configure system. The "dynamic" OpenGL build configuration must still be present and must be the default (because we want to OpenGL proper -> opengl32sw.dll fallback, the only difference now is that there is no ANGLE option between those two)
- the CI autotest situation has to be evaluated carefully once ANGLE is removed. As of Qt 5.15, all MSVC configs that run tests use ANGLE (with WARP) to run autotests, such as tst_qopenglwindow or tst_qrhi, and many Qt Quick autotests. The exception is the Win 7 MinGW config that runs with llvmpipe due to ANGLE failing to initialize in the Win7 VM. There is also a complication from the CMake migration: ANGLE has not been ported to CMake in the Qt source tree so therefore CMake-based builds are like -opengl desktop not -opengl dynamic. This means the affected autotests do not work it all in the CI VMs. If the tests get disabled as an interim solution, they will need to be reenabled when this task is done.
- UWP (WinRT) must be functional on QRhi with the D3D11 backend [depending on UWP support in Qt 6]
Attachments
Issue Links
- depends on
-
QTBUG-78575 UWP support in the D3D11 backend of QRhi
- Closed
- is required for
-
QTBUG-74411 Check and remove usage of OpenGL in other parts of Qt
- Closed
- relates to
-
QTBUG-74141 Port Windows ANGLE build to CMake
- Closed
-
QTBUG-79268 Purge direct OpenGL code path in Qt Quick
- Closed