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.
Related
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.
The upcoming Qt 5.6 introduces a blacklist to mark some graphic cards which are known to insufficiently support OpenGL or Angle.
Confirm e.g.
https://bugreports.qt.io/browse/QTBUG-47435
https://codereview.qt-project.org/#/c/140418/5//ALL
But what happens to QML apps on cards that have both disable_desktopgl and disable_angle set? Can those users not run QML apps at all?
They can't use OpenGL to accelerate Qt Quick, no. Which is a pretty severe drawback. Unfortunately the status of OpenGL on Windows is a nightmare. The "average" Windows computer will have an Intel-based GPU with ancient drivers, which are buggy enough to cause Qt not even try to use any 3D at all (OpenGL nor Direct3D). NVIDIA and AMD are usually better, as at least they tend to be more up-to-date.
Usually upgrading the Intel drivers solves most issues, but you are not always in the position of asking your users to upgrade their drivers (they might not even be able to do so, for instance lacking administrator privileges, and/or using laptops where the driver version has been pinned by the vendor).
Note that even other projects, such as Chromium or Firefox, have their own fine-grained driver bug blacklists (example).
In case your card is totally blacklisted you can:
use an OpenGL CPU implementation, such as Mesa. If you ship opengl32sw.dll with your application, it can be picked up by Qt. See the explaination here.
use the Qt Quick 2D renderer, which is a specialized CPU-based renderer for a subset of Qt Quick items. Compared to Mesa it's incredibly faster (because it doesn't need to go through the OpenGL pipeline in order to draw, say, a rectangle -- it can just draw the rectangle using a 2D rasterizer); on the other hand, certain things stop working, like shader effects. Currently it's available only under a commercial license, but in 5.8 it's going to be open source.
(Nitpick: QML is the language, Qt Quick is the framework/library to build UIs which you program using QML).
What is the difference between Qt versions with dynamic and desktop OpenGL? http://tver-soft.org/qt64
It is likley that this refers to the configure option that was set when they compiled Qt.
This option is explained in detail here: https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/
To summarise, Qt can be compiled to use ether the desktop OpenGL (a direct interface to the graphics driver provided OpenGL version) or to use Angle (a version of OpenGL that uses directX to provide hardware GL support).
Using 'desktop' gives you the latest (and deprecated) OpenGL features where available, but some drivers do not work properly.
Qt now relies on OpenGL to do important 2D rendering and can be badly affected by faulty drivers. For this reason you have the safer option of Angle, safer but limited to OpenGL ES 2.0 functionality.
Dinamic is a new option that will select between them automatically at runtime on the user's machine. It does however mean that you will need to use the Qt OpenGL API (rather than e.g. GLEW) to access OpenGL.
If you are not going to use OpenGL directly in your code then you should chose dynamic.
You should also consider compiling the code for yourself, as you are trusting your and your user's security to tver-soft.org. Even without malicious intent these files may be a security risk.
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'm developing an application that makes use of Qt and OpenGL, using Qt Creator and QGLWidget subclassing.
My application has a user base that has a higher than average proportion of older hardware, which is why I need it to run on machines with graphics cards supporting OpenGL 2.1 only - or, in other words, I cannot rely on anything newer than 2.1 being present.
I am worried about unknowingly using OpenGL functionality that was introduced after 2.1. Is there any way I can configure OpenGL to "only" support 2.1, so that I would get a runtime error if I do something I shouldn't be doing? Or, failing that, what is the best practice to ensure compatibility?
The only thing you need to worry about is not creating a OpenGL-3 core profile context, and only to use functions found in the OpenGL-2.1 specification.
Since creating a OpenGL-3 core context requires you to jump some hoops, you're not running into problems there. The system may give you something newer than OpenGL-2.1 but as long as you don't use any functionality not found in the 2.1 specification document you're fine. You'll have to use the extension mechanism, to actually get the functionality on Windows; OpenGL-2.1 is technically a list of extensions made official functionality, so carefully read the Appendix of the specification, where the functionality that formerly were extensions are explicitly mentioned.