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.
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.
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).
When downloading from this site http://qt-project.org/downloads
There are different versions like versions with OpenGL and versions without OpenGL, what is the different between them ?
Some time ago Google did develop a OpenGL emulation wrapper called ANGLE, to implement conformant WebGL on systems without a proper OpenGL installation, yet with sufficient Direct3D support. Qt makes internally use of OpenGL in some modules/classes. The non OpenGL downloads of Qt are linked with ANGLE to reliably enable this, even without proper OpenGL drivers on the system. The OpenGL versions of the download use the systems native OpenGL.
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'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.