diff options
author | Laszlo Agocs <laszlo.agocs@qt.io> | 2021-01-02 19:42:06 +0100 |
---|---|---|
committer | Laszlo Agocs <laszlo.agocs@qt.io> | 2021-01-04 17:30:43 +0100 |
commit | 587fed817aec5a435fb6467cd42b77831271ec34 (patch) | |
tree | 74a8f3b820a53a0e3317b8e80931f8e0002629b3 /src/gui/kernel/qplatformintegration.cpp | |
parent | 8da171a5aee304421ca0cd2f5c20c9bfa8205dc1 (diff) |
Add a platform capability indicating support for QRhi-based rendering
This attempts to reconcile a minor difference between Qt 5 and Qt 6:
Running Qt Quick applications with a platform plugin such as vnc,
led to an automatic fallback to the 'software' backend based on
the OpenGL capability reported from the platform plugin. In Qt 6.0
this logic is gone from Qt Quick, because we do not have, and wish
not to have, individual flags for each and every 3D API on this
level.
Therefore in Qt 6.0 a Qt Quick application running with the vnc
(or linuxfb, or minimal) platform needs an explicit selection of
the software backend via QT_QUICK_BACKEND or
QQuickWindow::setGraphicsApi().
To keep migration for users of such platform plugins easier, we
can still reintroduce a Qt 5-like logic: by having a high level
Is-QRhi-Supported type of flag, we can make Qt Quick query that,
and trigger the fallback to the software backend when it is
reported as false by the platform plugin. As this is the minority
case and a conscious choice by platform plugins, the flag can be
opt-out (i.e. true by the default hasCapability implementation).
When it comes to the existing OpenGL flag, that needs to stay for
compatibility reasons, but it is worth noting that the new flag
semantically falls in the exact same category: it does not indicate
things will really work at run time, but rather serves as an opt-out,
"do not even try" type of declaration the platform plugin can make,
which then allows modules like Qt Quick to make early, upfront
decisions about which rendering paths/backends to take.
Change-Id: I8d6fddeb82ca6eece7b7abc1a5b64ebe6d8af29d
Task-number: QTBUG-89561
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Diffstat (limited to 'src/gui/kernel/qplatformintegration.cpp')
-rw-r--r-- | src/gui/kernel/qplatformintegration.cpp | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/src/gui/kernel/qplatformintegration.cpp b/src/gui/kernel/qplatformintegration.cpp index ff0c9ae255..a53f0d09d7 100644 --- a/src/gui/kernel/qplatformintegration.cpp +++ b/src/gui/kernel/qplatformintegration.cpp @@ -251,6 +251,15 @@ QPlatformServices *QPlatformIntegration::services() const \value PaintEvents The platform sends paint events instead of expose events when the window needs repainting. Expose events are only sent when a window is toggled from a non-exposed to exposed state or back. + + \value RhiBasedRendering The platform supports one or more of the 3D rendering APIs + that Qt Quick and other components can use via the Qt Rendering Hardware Interface. On + platforms where it is clear upfront that the platform cannot, or does not want to, + support rendering via 3D graphics APIs such as OpenGL, Vulkan, Direct 3D, or Metal, + this capability can be reported as \c false. That in effect means that in modules + where there is an alternative, such as Qt Quick with its \c software backend, an + automatic fallback to that alternative may occur, if applicable. The default + implementation of hasCapability() returns \c true. */ /*! @@ -275,7 +284,7 @@ QPlatformServices *QPlatformIntegration::services() const bool QPlatformIntegration::hasCapability(Capability cap) const { return cap == NonFullScreenWindows || cap == NativeWidgets || cap == WindowManagement - || cap == TopStackedNativeChildWindows || cap == WindowActivation; + || cap == TopStackedNativeChildWindows || cap == WindowActivation || cap == RhiBasedRendering; } QPlatformPixmap *QPlatformIntegration::createPlatformPixmap(QPlatformPixmap::PixelType type) const |