I have a Qt application that draws using Open GL. At some point I'm using a QQuickWindow associated to a QQuickRenderControl to draw a QML scene into a texture to later compose it in the final image.
Now, I'm considering porting OpenGL to Vulkan and I'm not sure if it is possible to do the same with this QML layer.
Reading Qt docs I found that
QQuickWindow uses a scene graph on top of OpenGL to render.
Do you think it is possible to port it to Vulkan? Perhaps overriding QQuickWindow and QQuickRenderControl? I'm not a Qt expert so perhaps someone can give me a better insight of the problem.
As of June 2019 and Qt 5.13, Qt Quick 2 supports the following backends:
OpenGL 2.0
OpenGL ES 2.0
Direct3D 12 (support is still experimental)
OpenVG
Software rendering
However, only OpenGL and OpenGL ES are fully functional. For instance some effects (like particles) do not work with the other banckends.
For more information about how to select a backend and what are the limitations of each backend I suggest to read the documentation: https://doc.qt.io/qt-5/qtquick-visualcanvas-adaptations.html
Regarding Vulkan specifically, Qt has added support to it since Qt 5.10.
However, the support is still very limited and does not cover Qt Quick.
Change will come in the future; quoting an email from Qt development mailing list:
A very early preview of Qt Quick for Vulkan, Metal, and D3D11 may come already in Qt 5.14, then evolve in 5.15 and beyond, with 6.0 as its final destination.
So rendering Qt Quick with Vulkan should be possible when Qt 6 will be out. The planned release date for Qt 6 is currently November 2020. In the mean time technical previews might be available starting with Qt 5.14.
I would not be too optimistic for anything before Qt 6 as (1) it will just be technical previews and (2) as far as I know, current official Qt binaries are not linked with Vulkan at all and you need to build Qt from source if you want to use Vulkan.
Related
I’m working now on some project built on Qt 5.2.1. The project makes some basic rendering (using QPixmap, GraphicsScene, etc). The goal is to switch this mechanism to OpenGL as quickly as possible. In addition we plan to move the whole project to Qt 5.10.
Is there some benefit first moving to Qt 5.10 and only then switch to OpenGL over first switching to OpenGL and afterwards move to Qt 5.10?
Is there possibility of some unexpected difficulties if we first switch to OpenGL (on Qt 5.2.1) and only then upgrading to Qt 5.10 (some features got deprecated or some new nice-to-use features appear)?
My experience with OpenGL on Qt is it being full of both old and new bugs, poor integration capabilities, poor platform support (Intel=NOPE) and no error handling of Qt-internals (e.g. context creation). At least of you use the built-in OpenGL-widgets.
That said there is much development going on right now of the Qt-OpenGL support, judging from which Qt-version certain OpenGL related features I have found in he manual. If you must use Qt-OpenGL, I would assume you get most features and few(er) bugs jumping onto latest and greatest.
Is OpenGL mandatory in order to run a Qt application made of QML pages ?
Well, an implementation of OpenGL ES 2 is mandatory for Qt Quick 2, but that doesn't mean you need to use native OpenGL. On Windows you really should be using ANGLE, since on many Windows systems the installed OpenGL is either too old or broken.
Yes, with Qt Quick 2.0 OpenGL is a mandatory requirement.
I'm developer on Windows and I have some experiences on WinAPI programs.
As far as I know, there are two ways to draw on Windows, call GDI (includes wrapper of GDI like GDI+) to do traditional drawing or call some APIs like DX or OpenGL to draw use GPU.
But what other things like Qt are? Does Qt calls GDI finally to draw something? Or it just has its own way to draw directly?
I just want to know its theory in general.
Qt widgets use custom software renderer (custom raster engine) - it's not GDI from what it seems.
https://doc.qt.io/qt-5/topics-graphics.html
every widget inherits from QPaintDevice you can check the type of paint device: https://doc.qt.io/qt-5/qpaintengine.html#Type-enum
QtQuick seems to be using ANGLE (will convert ogl calls to d3d on windows) / pure OpenGL - https://blog.qt.io/blog/2017/01/18/opengl-implementation-qt-quick-app-using-today/
From the looks of it, since QT 4.0 they had changed the use of GDI and replaced it with some other internals that might improve portability, if you wish, QT is open sourced, so you may look at the code to understand QTGUI.dll internals.
I do not know this in practice, but the answer at http://qt-project.org/forums/viewthread/33565 seems reliable.
UPDATE: This page seems to be more accurate: http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL
Qt 5 on Windows can be configured to use either OpenGL drivers, or
DirectX drivers through the ANGLE library. What you want depends on
your use case. The Qt project offers binary installers for both
variants. OpenGL
OpenGL (Open Graphics Library) is a wide spread industry standard
[opengl.org] for rendering 2D and 3D computer graphics. It’s the
de-facto standard for hardware-accelerated graphics operations on Mac
OS X, Linux, and most embedded platforms.
OpenGL ES 2.0 (Open Graphics Library for Embedded Systems) is a
stripped-down version of OpenGL for use on embedded systems, which is
missing some functions.
The Qt Quick 2 stack in Qt 5 is based on OpenGL, and requires OpenGL
3.0 (alternatively OpenGL 2.x with the framebuffer_object extension) or higher or OpenGL ES 2.0. The Qt OpenGL module [qt-project.org]
requires OpenGL 1.3 or later. OpenGL on Windows
Although Microsoft Windows has native support for OpenGL since quite
some time, the supported standard version (version 1 without any
drivers installed) is too limited for Qt . Newer versions are
generally available through custom graphics drivers, but require users
to install them. Also, the quality of the OpenGL support by some
drivers is lacking. ANGLE Project
ANGLE (Almost Native Graphics Layer Engine) is an open source project
[code.google.com] by Google. Its aim is to map OpenGL ES 2.0 API calls
to DirectX 9 API. A regularly updated version of it is part of qtbase
[qt.gitorious.org] .
To compile Qt with ANGLE you have to have a Direct X SDK
[msdn.microsoft.com] installed. Starting from Windows Kit 8, this is
included in the Windows SDK.
If ANGLE is used in your application, you should ship
d3dcompiler_XX.dll along with the Qt libraries. The version string of
the D3D shader compiler is pulled from the DirectX SDK header, so make
sure to get the same version that ANGLE was built with (e.g. _43 or
_46). This becomes especially important if you configure Qt with -angle-d3d11. Recommendations Use Desktop OpenGL if Your application uses OpenGL calls not part of OpenGL ES 2.0 Your application does not
use OpenGL at all (since ANGLE implies additional deployment
dependencies which are then not needed). Your application needs to run
on Windows XP. Although it is tempting to use ANGLE as a replacement
for missing graphics drivers on this platform, it does not fully work
and may lead to crashes, for example, when the security dialog is
opened.
Use ANGLE if You need OpenGL ES features, but not full OpenGL You have
a heterogeneous user base with different Windows versions & graphics
cards You do not want your user to have to install a recent graphics
card driver You want to use the video playback functionality of
QtMultimedia (see QTBUG-31800 [bugreports.qt-project.org] ) Your
application needs to run over Windows Remote Desktop Protocol (see
OpenGL and Remote Desktop [social.technet.microsoft.com])
Further Reading
http://qt-project.org/doc/qt-5.1/qtdoc/requirements-win.html
http://qt-project.org/doc/qt-5.1/qtopengl/qtopengl-index.html
http://blog.qt.digia.com/blog/2012/10/24/graphics-on-windows-from-a-different-angle/
http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx
I have installed Qt5 libraries in windows but there is no document about Qt3D in Qt assistant.
Is Qt3D a part of Qt5 or it has been removed from release version 5?
Yes. Qt 3D became a standard Qt library in the Qt 5.7 release.
With Qt 5.7, we are bringing in the Qt 3D module. This module has been
available as a Technology Preview for two releases now, and I’m happy
to announce that it has now reached the state where it is becoming a
fully supported member of the Qt family!
This addition was a long time coming. Roughly 4.5 years ago, they announced they were dropping it from the Qt 5.0 release. Since then, it's undergone significant rework. Now, seven minor versions later, it's finally made it back in.
The other answer & comments were correct at the time, but the situation has now changed.
As of Qt5.5, Qt3D is now included as a "technology preview" (I interpret this phrase as an indication that it's not deployment-ready, so there could be some bugs and the API could change).
It's very important to note that the Qt3D that was available for previous versions of Qt has been Qt3D 1.0, while the version included with Qt5.5 is v2.0, which has been developed by a different software team and has a very different API.
More info from the new developers available here.
Note also that Qt3D v1.0 was never actually included 'properly' with Qt in any version, though was (apparently) reasonably easy to build along with Qt if checked out from git from v5.0 through 5.4.
I have a few questions about Qt.
I already know that Qt and OpenGL can be used together. At the
moment we are using GLUT at my university (for window and input
management). I saw that Qt is able to do the same thing. Are there
any disadvantages of using Qt instead of GLUT? (performance
wise)
I also know that Qt can be used to build a ingame GUI. I even saw
this 3d GUI example WolfenQt. So it is possible. But does it
make sense to use Qt for an ingame GUI if you care about
perfomance?
Qt, like any other tool can be misused. But just because you use Qt this does not mean, OpenGL performance will suffer. OpenGL doesn't care about what and how its context and the drawable it's bound to are created. The biggest impact Qt has is, how it manages and delivers events; the signal/slots mechanism.