• Technical task
    • Resolution: Done
    • P2: Important
    • 6.0
    • QPA: Windows, Qt RHI
    • None
    • Windows, WinRT
    • 752497910b67b2a1a80560840ca44548d8893434 (qt/qtbase/dev)


      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]


        Issue Links

          For Gerrit Dashboard: QTBUG-79103
          # Subject Branch Project Status CR V



              lagocs Laszlo Agocs
              lagocs Laszlo Agocs
              0 Vote for this issue
              5 Start watching this issue



                Gerrit Reviews

                  There are no open Gerrit changes