[Development] Quick2 and Directx11 backend (Angle)

Corentin Jabot corentin.jabot at gmail.com
Sun May 20 15:24:20 CEST 2012

So, There is the patch.

* First, checkout and build ANGLE as explain here
http://code.google.com/p/angleproject/wiki/DevSetup ( require directx sdk &
 visual studio )
* Then, edit qtbase/mkspecs/features/win32/opengl.prf and change the
include and library path of angle ( or just build angle in C:\\angle)
* Run configure.exe with the option "-opengl es2"
* Build qtbase, it should works fine.
* Build and test some examples.

examples\opengl\hellowindow work just fine.
The others do not : black screen, crash, etc.
I'm not so sure where the problem really is, that is why I seek help

How does it work ?
When configured with -opengl es2,  the windows QPA will use an EGL contexts
and surfaces instead of opengl. the EGL calls are
converted transparently by ANGLE into directx calls.

Remaining work :
* Try and fixes the black screen, crashes, and others issues ( like
ui unresponsiveness)
* Clean the code
* Integrate nicely with QSurfaceFormat and find optimal options.
* Ensure QtDeclarative and other modules works fine on top of angle

* I thought of including ANGLE in the Qt sources, so it
can automatically be build via some configure option, but sadly ANGLE is
not designed to compile with MINGW.
* ANGLE provide an OpenGL ES 2.0 API, not an Opengl API. So examples,
applications or features that specifically require a full opengl api are
not supposed to work.

I'm convinced that this kind of work is really important for QML adoption
since a lot of final Windows users do not have a working opengl support  -
mostly because they use outdated drivers, and they can be hard to update,
especially on laptops.
The ultimate solution would be to use ANGLE as a fallback if
the initialization of a classic opengl context fail, but that seems a
really laborious task.
Also, Thiago mentioned a cpu-rasterization project, I guess that would make
ANGLE useless, but I'm not sure there is people working on that.  And the
performance of such solution wouldn't be so great.

Please note that patch is very unstable and experimental. The patch is
quite ugly, I put some code in place it does not belong (see
QEGLPlatformContext constructor ) and added a lot of logs to figure what go
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120520/62dc775c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: angle.patch
Type: application/octet-stream
Size: 21471 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120520/62dc775c/attachment.obj>

More information about the Development mailing list