A just curious question.
I'm aware that:
Skia, Cairo: library
Direct2D: API
But without any additional components, exclusively on Windows platform, which bears the most features? I'm not talking about performance or programming simplicity.
Is there any possibility that Cairo could use D2D as the rendering backend on Windows platform?
I am using all three in my Sciter as graphics backends so you can compare them in action.
As of today (Nov 20, 2017):
Feature set:
Skia and Direct2D are on par by feature set.
And both are feature wise supersets of Cairo.
From these three, only Direct2D (Direct2D v 1.1) supports printing. Skia and Cairo instead are capable of PDF generation so for real printing you will need 3rd party tools.
3D integration:
Direct2D has good integration with DirectX - they can work on the same DXGI device.
But it is far not that trivial to integrate Skia with existing 3D OpenGL code. Even Skia can work with OpenGL backend it changes state of OpenGL device and that creates problems.
Performance:
With Direct2D you can reach 60-250 FPS.
On Windows, Skia when used with OpenGL backend may surprisingly work better than Direct2D. But YMMV.
Platforms:
On Windows I'd suggest to use Direct2D or Skia.
On MacOS - definitely Skia with OpenGL backend. It is significantly better than Mac's native CoreGraphics.
On Linux/GTK: use Cairo as this is the default rendering API on GTK/Gnome3. And Cairo works there pretty well.
Related
I would appreciate clarity around hardware acceleration supported for ML Kit. Some applications make an explicit mention that models are run on CPU, implying that there can be other modes of acceleration. Using GPU via something like OpenCL seems like a natural way of doing so.
I wish to know if Google is capable and willing of mastering OpenCL for Machine Learning applications.
Currently, ML Kit features are all running in CPU to be compatible with all devices. We are adding GPU / NNAPI support for features, and will update them in future releases.
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'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 wonder if my standalone application that gui is being made using JavaFX 2.1 would run on a quite old computer with Windows XP, because this app is intended to work on that computer. I'm asking because I'm begginer to JavaFX and it seems like that technology has quite high requirments, last time I've got warning: "bad driver version detected, device disabled. Please update your driver to at least version 8.15.10.2302".
If your machine meets the minimum system hardware requirements and you have a recent graphics driver installed, then JavaFX 2.1 should work on your Windows XP machine.
Whether JavaFX will work on a machine depends on the hardware in the machine as well as the graphics driver installed.
Here are the JavaFX 2.1 system requirements.
The version string you reference would appear to be for an integrated Intel chipset graphics driver. You can download current versions of such drivers from Intel.
Update
If your system does not support hardware acceleration, then JavaFX
uses the Java2D software pipeline" - just to be sure, my program will
still work, but with poorer graphic, right?
At least in some cases with older drivers, it would seem that the app will work by falling back to a software pipeline. While this kind of fallback will work for a large percentage of older hardware and software combinations, I don't think it is fully tested given a wide variety of older hardware and driver combinations and I don't think there is a guarantee that the program will still run as expected.
The below outlines my experience with JavaFX 2.0 and 2.1.
If the graphics hardware is not listed in the JavaFX system requirements as being supported for hardware acceleration, then JavaFX will fall back to the software renderer and the app will work (albeit with potentially reduced performance and lack of access to some conditional features such as (perhaps) effects or 3D rendering). This scenario should be pretty uncommon as JavaFX supports a wide variety of hardware acceleration hardware.
If the graphics hardware is listed in the JavaFX system requirements as being supported for hardware acceleration and the drivers are up to date, then JavaFX will use the hardware renderer and your app will work. This is by far the most common scenario - any desktop purchased in the last few years should meet the minimum JavaFX hardware acceleration specifications and driver requirements.
If the graphics hardware is listed in the JavaFX system requirements as being supported for hardware acceleration and the drivers are not at a level required for JavaFX to function correctly, then the app may not work (the app may fallback to the software pipeline and continue running or you may get a message stating that the drivers need updating) or the app will just start experiencing rendering errors and possibly freezing or crashing. This scenario should only occur on a very low percentage of possible runtime targets.
If you have instances of hardware and driver combinations where JavaFX is not behaving as you would wish (i.e. not correctly executing your program, logging spurious exceptions or freezing and crashing), then file a jira issue with the hardware and software specifications to get the JavaFX team to look into providing support for that combination.