2022-05-13 13:12:05 +00:00
|
|
|
// Copyright (C) 2016 The Qt Company Ltd.
|
|
|
|
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
|
2013-10-17 12:53:33 +00:00
|
|
|
|
Mark the module as free of Q_FOREACH, except where it isn't
The density of Q_FOREACH uses is high here, too high for this author,
unfamiliar with this code, to tackle in a short amount of time. But
they're concentrated in just a few TUs, so pick a different strategy:
Mark the whole module with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too). Created QTBUG-115808 to keep track of
this.
Task-number: QTBUG-115808
Change-Id: I29c377f939e3d747e3ce72c224c4ee722df7a95d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2023-08-06 15:03:37 +00:00
|
|
|
#undef QT_NO_FOREACH // this file contains unported legacy Q_FOREACH uses
|
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
#include <qtest.h>
|
|
|
|
|
2016-11-16 13:22:36 +00:00
|
|
|
#if QT_CONFIG(opengl)
|
2014-06-04 18:32:07 +00:00
|
|
|
#include <QOffscreenSurface>
|
|
|
|
#include <QOpenGLContext>
|
|
|
|
#include <QOpenGLFunctions>
|
2016-04-25 10:09:44 +00:00
|
|
|
#endif
|
2014-06-04 18:32:07 +00:00
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
#include <QtQuick>
|
2014-06-04 18:32:07 +00:00
|
|
|
#include <QtQml>
|
2013-10-17 12:53:33 +00:00
|
|
|
|
2016-11-16 13:22:36 +00:00
|
|
|
#if QT_CONFIG(opengl)
|
2014-06-04 16:59:58 +00:00
|
|
|
#include <private/qopenglcontext_p.h>
|
2016-04-25 10:09:44 +00:00
|
|
|
#endif
|
|
|
|
|
2014-06-04 18:32:07 +00:00
|
|
|
#include <private/qsgcontext_p.h>
|
|
|
|
#include <private/qsgrenderloop_p.h>
|
2020-06-05 13:28:57 +00:00
|
|
|
#include <private/qsgrhisupport_p.h>
|
2021-09-03 11:27:57 +00:00
|
|
|
#include <private/qsgplaintexture_p.h>
|
2013-10-17 12:53:33 +00:00
|
|
|
|
2021-08-06 10:27:35 +00:00
|
|
|
#include <QtQuickTestUtils/private/qmlutils_p.h>
|
|
|
|
#include <QtQuickTestUtils/private/visualtestutils_p.h>
|
2016-03-22 02:31:03 +00:00
|
|
|
|
2017-08-30 12:39:28 +00:00
|
|
|
#include <QtGui/private/qguiapplication_p.h>
|
|
|
|
#include <QtGui/qpa/qplatformintegration.h>
|
|
|
|
|
2021-08-06 10:27:35 +00:00
|
|
|
using namespace QQuickVisualTestUtils;
|
2013-10-17 12:53:33 +00:00
|
|
|
|
2014-08-04 08:10:10 +00:00
|
|
|
class PerPixelRect : public QQuickItem
|
|
|
|
{
|
|
|
|
Q_PROPERTY(QColor color READ color WRITE setColor NOTIFY colorChanged)
|
|
|
|
Q_OBJECT
|
|
|
|
public:
|
|
|
|
PerPixelRect() {
|
|
|
|
setFlag(ItemHasContents);
|
|
|
|
}
|
|
|
|
|
|
|
|
void setColor(const QColor &c) {
|
|
|
|
if (c == m_color)
|
|
|
|
return;
|
|
|
|
m_color = c;
|
|
|
|
emit colorChanged(c);
|
|
|
|
}
|
|
|
|
|
|
|
|
QColor color() const { return m_color; }
|
|
|
|
|
2021-03-25 13:44:04 +00:00
|
|
|
QSGNode *updatePaintNode(QSGNode *node, UpdatePaintNodeData *) override
|
2014-08-04 08:10:10 +00:00
|
|
|
{
|
Add the graphics api independent scenegraph port
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-04-23 07:40:59 +00:00
|
|
|
delete node;
|
|
|
|
node = new QSGNode;
|
|
|
|
|
2019-07-12 11:17:02 +00:00
|
|
|
const int w = int(width());
|
|
|
|
const int h = int(height());
|
Add the graphics api independent scenegraph port
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-04-23 07:40:59 +00:00
|
|
|
QQuickWindow *win = window();
|
|
|
|
for (int y = 0; y < h; ++y) {
|
|
|
|
for (int x = 0; x < w; ++x) {
|
|
|
|
QSGRectangleNode *rn = win->createRectangleNode();
|
2014-08-04 08:10:10 +00:00
|
|
|
rn->setRect(x, y, 1, 1);
|
|
|
|
rn->setColor(m_color);
|
|
|
|
node->appendChildNode(rn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return node;
|
|
|
|
}
|
|
|
|
|
|
|
|
Q_SIGNALS:
|
Add the graphics api independent scenegraph port
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-04-23 07:40:59 +00:00
|
|
|
void colorChanged(const QColor &c);
|
2014-08-04 08:10:10 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
QColor m_color;
|
|
|
|
};
|
|
|
|
|
2016-08-03 18:01:58 +00:00
|
|
|
class tst_SceneGraph : public QQmlDataTest
|
2013-10-17 12:53:33 +00:00
|
|
|
{
|
|
|
|
Q_OBJECT
|
|
|
|
|
2021-08-06 10:27:35 +00:00
|
|
|
public:
|
|
|
|
tst_SceneGraph();
|
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
private slots:
|
2021-02-23 08:46:23 +00:00
|
|
|
void initTestCase() override;
|
2014-08-04 08:10:10 +00:00
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
void manyWindows_data();
|
|
|
|
void manyWindows();
|
|
|
|
|
2013-10-31 21:22:54 +00:00
|
|
|
void render_data();
|
|
|
|
void render();
|
2016-11-16 13:22:36 +00:00
|
|
|
#if QT_CONFIG(opengl)
|
2013-11-18 07:53:13 +00:00
|
|
|
void hideWithOtherContext();
|
2016-04-25 10:09:44 +00:00
|
|
|
#endif
|
2015-06-11 08:17:45 +00:00
|
|
|
void createTextureFromImage_data();
|
|
|
|
void createTextureFromImage();
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
void withAdoptedRhi();
|
2021-09-03 11:27:57 +00:00
|
|
|
void resizeTextureFromImage();
|
2015-06-11 08:17:45 +00:00
|
|
|
|
2015-03-27 10:32:27 +00:00
|
|
|
private:
|
2018-02-21 09:41:54 +00:00
|
|
|
QQuickView *createView(const QString &file, QWindow *parent = nullptr, int x = -1, int y = -1, int w = -1, int h = -1);
|
Add the graphics api independent scenegraph port
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-04-23 07:40:59 +00:00
|
|
|
bool isRunningOnRhi();
|
2013-10-17 12:53:33 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
template <typename T> class ScopedList : public QList<T> {
|
|
|
|
public:
|
|
|
|
~ScopedList() { qDeleteAll(*this); }
|
|
|
|
};
|
|
|
|
|
2021-08-06 10:27:35 +00:00
|
|
|
tst_SceneGraph::tst_SceneGraph()
|
|
|
|
: QQmlDataTest(QT_QMLTEST_DATADIR)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-08-04 08:10:10 +00:00
|
|
|
void tst_SceneGraph::initTestCase()
|
|
|
|
{
|
|
|
|
qmlRegisterType<PerPixelRect>("SceneGraphTest", 1, 0, "PerPixelRect");
|
2014-06-04 18:32:07 +00:00
|
|
|
|
2016-08-03 18:01:58 +00:00
|
|
|
QQmlDataTest::initTestCase();
|
|
|
|
|
2014-06-04 18:32:07 +00:00
|
|
|
QSGRenderLoop *loop = QSGRenderLoop::instance();
|
2020-06-05 13:28:57 +00:00
|
|
|
qDebug() << "RenderLoop:" << loop
|
|
|
|
<< "RHI backend:" << QSGRhiSupport::instance()->rhiBackendName();
|
2014-08-04 08:10:10 +00:00
|
|
|
}
|
|
|
|
|
2016-08-03 18:01:58 +00:00
|
|
|
QQuickView *tst_SceneGraph::createView(const QString &file, QWindow *parent, int x, int y, int w, int h)
|
2013-10-17 12:53:33 +00:00
|
|
|
{
|
|
|
|
QQuickView *view = new QQuickView(parent);
|
2016-08-03 18:01:58 +00:00
|
|
|
view->setSource(testFileUrl(file));
|
2013-10-17 12:53:33 +00:00
|
|
|
if (x >= 0 && y >= 0) view->setPosition(x, y);
|
|
|
|
if (w >= 0 && h >= 0) view->resize(w, h);
|
|
|
|
view->show();
|
|
|
|
return view;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Assumes the images are opaque white...
|
|
|
|
bool containsSomethingOtherThanWhite(const QImage &image)
|
|
|
|
{
|
2016-05-06 10:48:04 +00:00
|
|
|
QImage img;
|
|
|
|
if (image.format() != QImage::Format_ARGB32_Premultiplied
|
|
|
|
|| image.format() != QImage::Format_RGB32)
|
|
|
|
img = image.convertToFormat(QImage::Format_ARGB32_Premultiplied);
|
|
|
|
else
|
|
|
|
img = image;
|
|
|
|
|
|
|
|
int w = img.width();
|
|
|
|
int h = img.height();
|
2013-10-17 12:53:33 +00:00
|
|
|
for (int y=0; y<h; ++y) {
|
2016-05-06 10:48:04 +00:00
|
|
|
const uint *pixels = (const uint *) img.constScanLine(y);
|
2013-10-17 12:53:33 +00:00
|
|
|
for (int x=0; x<w; ++x)
|
|
|
|
if (pixels[x] != 0xffffffff)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void tst_SceneGraph::manyWindows_data()
|
|
|
|
{
|
|
|
|
QTest::addColumn<QString>("file");
|
|
|
|
QTest::addColumn<bool>("toplevel");
|
2013-10-30 13:32:54 +00:00
|
|
|
QTest::addColumn<bool>("shared");
|
|
|
|
|
|
|
|
QTest::newRow("image,toplevel") << QStringLiteral("manyWindows_image.qml") << true << false;
|
|
|
|
QTest::newRow("image,subwindow") << QStringLiteral("manyWindows_image.qml") << false << false;
|
|
|
|
QTest::newRow("dftext,toplevel") << QStringLiteral("manyWindows_dftext.qml") << true << false;
|
|
|
|
QTest::newRow("dftext,subwindow") << QStringLiteral("manyWindows_dftext.qml") << false << false;
|
|
|
|
QTest::newRow("ntext,toplevel") << QStringLiteral("manyWindows_ntext.qml") << true << false;
|
|
|
|
QTest::newRow("ntext,subwindow") << QStringLiteral("manyWindows_ntext.qml") << false << false;
|
|
|
|
QTest::newRow("rects,toplevel") << QStringLiteral("manyWindows_rects.qml") << true << false;
|
|
|
|
QTest::newRow("rects,subwindow") << QStringLiteral("manyWindows_rects.qml") << false << false;
|
|
|
|
|
|
|
|
QTest::newRow("image,toplevel,sharing") << QStringLiteral("manyWindows_image.qml") << true << true;
|
|
|
|
QTest::newRow("image,subwindow,sharing") << QStringLiteral("manyWindows_image.qml") << false << true;
|
|
|
|
QTest::newRow("dftext,toplevel,sharing") << QStringLiteral("manyWindows_dftext.qml") << true << true;
|
|
|
|
QTest::newRow("dftext,subwindow,sharing") << QStringLiteral("manyWindows_dftext.qml") << false << true;
|
|
|
|
QTest::newRow("ntext,toplevel,sharing") << QStringLiteral("manyWindows_ntext.qml") << true << true;
|
|
|
|
QTest::newRow("ntext,subwindow,sharing") << QStringLiteral("manyWindows_ntext.qml") << false << true;
|
|
|
|
QTest::newRow("rects,toplevel,sharing") << QStringLiteral("manyWindows_rects.qml") << true << true;
|
|
|
|
QTest::newRow("rects,subwindow,sharing") << QStringLiteral("manyWindows_rects.qml") << false << true;
|
2013-10-17 12:53:33 +00:00
|
|
|
}
|
|
|
|
|
2016-11-16 13:22:36 +00:00
|
|
|
#if QT_CONFIG(opengl)
|
2013-10-30 13:32:54 +00:00
|
|
|
struct ShareContextResetter {
|
|
|
|
public:
|
2018-02-21 09:41:54 +00:00
|
|
|
~ShareContextResetter() { qt_gl_set_global_share_context(nullptr); }
|
2013-10-30 13:32:54 +00:00
|
|
|
};
|
2016-04-25 10:09:44 +00:00
|
|
|
#endif
|
2013-10-30 13:32:54 +00:00
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
void tst_SceneGraph::manyWindows()
|
|
|
|
{
|
2017-08-30 12:39:28 +00:00
|
|
|
if ((QGuiApplication::platformName() == QLatin1String("offscreen"))
|
|
|
|
|| (QGuiApplication::platformName() == QLatin1String("minimal")))
|
2020-03-18 13:24:29 +00:00
|
|
|
QSKIP("Skipping due to grabWindow not functional on offscreen/minimal platforms");
|
2017-08-30 12:39:28 +00:00
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
QFETCH(QString, file);
|
|
|
|
QFETCH(bool, toplevel);
|
2013-10-30 13:32:54 +00:00
|
|
|
QFETCH(bool, shared);
|
2016-11-16 13:22:36 +00:00
|
|
|
#if QT_CONFIG(opengl)
|
2013-10-30 13:32:54 +00:00
|
|
|
QOpenGLContext sharedGLContext;
|
|
|
|
ShareContextResetter cleanup; // To avoid dangling pointer in case of test-failure.
|
|
|
|
if (shared) {
|
2015-01-26 08:25:15 +00:00
|
|
|
QVERIFY(sharedGLContext.create());
|
2014-06-04 18:32:07 +00:00
|
|
|
qt_gl_set_global_share_context(&sharedGLContext);
|
2013-10-30 13:32:54 +00:00
|
|
|
}
|
2016-04-25 10:09:44 +00:00
|
|
|
#endif
|
2013-10-17 12:53:33 +00:00
|
|
|
QScopedPointer<QWindow> parent;
|
|
|
|
if (!toplevel) {
|
|
|
|
parent.reset(new QWindow());
|
|
|
|
parent->resize(200, 200);
|
|
|
|
parent->show();
|
|
|
|
}
|
|
|
|
|
|
|
|
ScopedList <QQuickView *> views;
|
|
|
|
|
|
|
|
const int COUNT = 4;
|
|
|
|
|
|
|
|
QImage baseLine;
|
2018-12-14 09:20:06 +00:00
|
|
|
QString errorMessage;
|
2013-10-17 12:53:33 +00:00
|
|
|
for (int i=0; i<COUNT; ++i) {
|
|
|
|
views << createView(file, parent.data(), (i % 2) * 100, (i / 2) * 100, 100, 100);
|
|
|
|
}
|
|
|
|
for (int i=0; i<COUNT; ++i) {
|
|
|
|
QQuickView *view = views.at(i);
|
2018-02-21 08:16:14 +00:00
|
|
|
QVERIFY(QTest::qWaitForWindowExposed(view));
|
2013-10-17 12:53:33 +00:00
|
|
|
QImage content = view->grabWindow();
|
|
|
|
if (i == 0) {
|
|
|
|
baseLine = content;
|
|
|
|
QVERIFY(containsSomethingOtherThanWhite(baseLine));
|
|
|
|
} else {
|
2018-12-14 09:20:06 +00:00
|
|
|
QVERIFY2(compareImages(content, baseLine, &errorMessage),
|
|
|
|
qPrintable(errorMessage));
|
2013-10-17 12:53:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Wipe and recreate one (scope pointer delets it...)
|
|
|
|
delete views.takeLast();
|
|
|
|
QQuickView *last = createView(file, parent.data(), 100, 100, 100, 100);
|
2018-02-21 08:16:14 +00:00
|
|
|
QVERIFY(QTest::qWaitForWindowExposed(last));
|
2013-10-17 12:53:33 +00:00
|
|
|
views << last;
|
2018-12-14 09:20:06 +00:00
|
|
|
QVERIFY2(compareImages(baseLine, last->grabWindow(), &errorMessage),
|
|
|
|
qPrintable(errorMessage));
|
2013-10-17 12:53:33 +00:00
|
|
|
|
|
|
|
// Wipe and recreate all
|
|
|
|
qDeleteAll(views);
|
|
|
|
views.clear();
|
|
|
|
|
|
|
|
for (int i=0; i<COUNT; ++i) {
|
|
|
|
views << createView(file, parent.data(), (i % 2) * 100, (i / 2) * 100, 100, 100);
|
|
|
|
}
|
|
|
|
for (int i=0; i<COUNT; ++i) {
|
|
|
|
QQuickView *view = views.at(i);
|
2018-02-21 08:16:14 +00:00
|
|
|
QVERIFY(QTest::qWaitForWindowExposed(view));
|
2013-10-17 12:53:33 +00:00
|
|
|
QImage content = view->grabWindow();
|
2018-12-14 09:20:06 +00:00
|
|
|
QVERIFY2(compareImages(content, baseLine, &errorMessage),
|
|
|
|
qPrintable(errorMessage));
|
2013-10-17 12:53:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-31 21:22:54 +00:00
|
|
|
struct Sample {
|
2021-03-25 13:38:28 +00:00
|
|
|
constexpr Sample(int xx, int yy, qreal rr, qreal gg, qreal bb, qreal errorMargin = 0.05)
|
2013-10-31 21:22:54 +00:00
|
|
|
: x(xx)
|
|
|
|
, y(yy)
|
|
|
|
, r(rr)
|
|
|
|
, g(gg)
|
|
|
|
, b(bb)
|
|
|
|
, tolerance(errorMargin)
|
|
|
|
{
|
|
|
|
}
|
2021-03-25 13:38:28 +00:00
|
|
|
constexpr Sample(const Sample &o) : x(o.x), y(o.y), r(o.r), g(o.g), b(o.b), tolerance(o.tolerance) { }
|
|
|
|
constexpr Sample() : x(0), y(0), r(0), g(0), b(0), tolerance(0) { }
|
|
|
|
constexpr Sample &operator=(const Sample &o)
|
|
|
|
{
|
|
|
|
x = o.x;
|
|
|
|
y = o.y;
|
|
|
|
r = o.r;
|
|
|
|
g = o.g;
|
|
|
|
b = o.b;
|
|
|
|
tolerance = o.tolerance;
|
|
|
|
return *this;
|
|
|
|
}
|
2013-10-31 21:22:54 +00:00
|
|
|
|
|
|
|
QString toString(const QImage &image) const {
|
|
|
|
QColor color(image.pixel(x,y));
|
|
|
|
return QString::fromLatin1("pixel(%1,%2), rgb(%3,%4,%5), tolerance=%6 -- image(%7,%8,%9)")
|
|
|
|
.arg(x).arg(y)
|
|
|
|
.arg(r).arg(g).arg(b)
|
|
|
|
.arg(tolerance)
|
|
|
|
.arg(color.redF()).arg(color.greenF()).arg(color.blueF());
|
|
|
|
}
|
|
|
|
|
2014-06-04 18:32:07 +00:00
|
|
|
bool check(const QImage &image, qreal scale) {
|
2023-03-14 12:59:03 +00:00
|
|
|
const int scaledX = qRound(x * scale);
|
|
|
|
const int scaledY = qRound(y * scale);
|
|
|
|
const QColor color(image.pixel(scaledX, scaledY));
|
2013-10-31 21:22:54 +00:00
|
|
|
return qAbs(color.redF() - r) <= tolerance
|
|
|
|
&& qAbs(color.greenF() - g) <= tolerance
|
|
|
|
&& qAbs(color.blueF() - b) <= tolerance;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int x, y;
|
|
|
|
qreal r, g, b;
|
|
|
|
qreal tolerance;
|
|
|
|
};
|
|
|
|
|
2020-04-02 09:00:06 +00:00
|
|
|
static Sample sample_from_regexp(QRegularExpressionMatch *match) {
|
|
|
|
return Sample(match->captured(1).toInt(),
|
|
|
|
match->captured(2).toInt(),
|
|
|
|
match->captured(3).toFloat(),
|
|
|
|
match->captured(4).toFloat(),
|
|
|
|
match->captured(5).toFloat(),
|
|
|
|
match->captured(6).toFloat()
|
2013-10-31 21:22:54 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
Q_DECLARE_METATYPE(Sample);
|
|
|
|
|
|
|
|
/*
|
|
|
|
The render() test implements a small test framework for itself with
|
|
|
|
the purpose of testing odds and ends of the scene graph
|
|
|
|
rendering. Each .qml file can consist of one or two stages. The
|
|
|
|
first stage is when the file is first displayed. The content is
|
|
|
|
grabbed and matched against 'base' samples defined in the .qml file
|
|
|
|
itself. The samples contain a pixel position, and RGB value and a
|
|
|
|
margin of error. The samples are defined in the .qml file so it is
|
|
|
|
easy to make the connection between colors and positions on the screen.
|
|
|
|
|
|
|
|
If the base stage samples all succeed, the test emits
|
|
|
|
'enterFinalStage' on the root item and waits for the .qml file to
|
|
|
|
update the value of 'finalStageComplete' The test can set this
|
|
|
|
directly or run an animation and set it later. Once the
|
|
|
|
'finalStageComplete' variable is true, we grab and match against the
|
|
|
|
second set of samples 'final'
|
|
|
|
|
|
|
|
The samples in the .qml file are defined in comments on the format:
|
|
|
|
#base: x y r g b error-tolerance
|
|
|
|
#final: x y r g b error-tolerance
|
|
|
|
- x and y are integers
|
|
|
|
- r g b are floats in the range of 0.0-1.0
|
|
|
|
- error-tolerance is a float in the range of 0.0-1.0
|
|
|
|
|
|
|
|
We also include a
|
|
|
|
#samples: count
|
|
|
|
to sanity check that all base/final samples were matched correctly
|
|
|
|
as the matching regexp is a bit crude.
|
|
|
|
|
|
|
|
To add new tests, add them to the 'files' list and put #base,
|
|
|
|
#final, #samples tags into the .qml file
|
|
|
|
*/
|
|
|
|
|
|
|
|
void tst_SceneGraph::render_data()
|
|
|
|
{
|
|
|
|
QTest::addColumn<QString>("file");
|
|
|
|
QTest::addColumn<QList<Sample> >("baseStage");
|
|
|
|
QTest::addColumn<QList<Sample> >("finalStage");
|
|
|
|
|
|
|
|
QList<QString> files;
|
2016-08-03 18:01:58 +00:00
|
|
|
files << "render_DrawSets.qml"
|
|
|
|
<< "render_Overlap.qml"
|
|
|
|
<< "render_MovingOverlap.qml"
|
|
|
|
<< "render_BreakOpacityBatch.qml"
|
|
|
|
<< "render_OutOfFloatRange.qml"
|
|
|
|
<< "render_StackingOrder.qml"
|
|
|
|
<< "render_ImageFiltering.qml"
|
|
|
|
<< "render_bug37422.qml"
|
2020-06-05 13:28:57 +00:00
|
|
|
<< "render_OpacityThroughBatchRoot.qml"
|
2021-05-10 16:03:51 +00:00
|
|
|
<< "render_Mipmap.qml"
|
|
|
|
<< "render_AlphaOverlapRebuild.qml";
|
2013-10-31 21:22:54 +00:00
|
|
|
|
2020-04-02 09:00:06 +00:00
|
|
|
QRegularExpression sampleCount("#samples: *(\\d+)");
|
2013-10-31 21:22:54 +00:00
|
|
|
// X:int Y:int R:float G:float B:float Error:float
|
2020-04-02 09:00:06 +00:00
|
|
|
QRegularExpression baseSamples("#base: *(\\d+) *(\\d+) *(\\d\\.\\d+) *(\\d\\.\\d+) *(\\d\\.\\d+) *(\\d\\.\\d+)");
|
|
|
|
QRegularExpression finalSamples("#final: *(\\d+) *(\\d+) *(\\d\\.\\d+) *(\\d\\.\\d+) *(\\d\\.\\d+) *(\\d\\.\\d+)");
|
2013-10-31 21:22:54 +00:00
|
|
|
|
|
|
|
foreach (QString fileName, files) {
|
2016-08-03 18:01:58 +00:00
|
|
|
QFile file(testFile(fileName));
|
2013-10-31 21:22:54 +00:00
|
|
|
if (!file.open(QFile::ReadOnly)) {
|
|
|
|
qFatal("render_data: QFile::open failed! file=%s, error=%s",
|
|
|
|
qPrintable(fileName), qPrintable(file.errorString()));
|
|
|
|
}
|
|
|
|
QStringList contents = QString::fromLatin1(file.readAll()).split(QLatin1Char('\n'));
|
|
|
|
|
|
|
|
int samples = -1;
|
|
|
|
foreach (QString line, contents) {
|
2020-04-02 09:00:06 +00:00
|
|
|
auto match = sampleCount.match(line);
|
|
|
|
if (match.hasMatch()) {
|
|
|
|
samples = match.captured(1).toInt();
|
2013-10-31 21:22:54 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (samples == -1)
|
|
|
|
qFatal("render_data: failed to find string '#samples: [count], file=%s", qPrintable(fileName));
|
|
|
|
|
|
|
|
QList<Sample> baseStage, finalStage;
|
|
|
|
foreach (QString line, contents) {
|
2020-04-02 09:00:06 +00:00
|
|
|
auto match = baseSamples.match(line);
|
|
|
|
if (match.hasMatch())
|
|
|
|
baseStage << sample_from_regexp(&match);
|
|
|
|
else if ((match = finalSamples.match(line)).hasMatch())
|
|
|
|
finalStage << sample_from_regexp(&match);
|
2013-10-31 21:22:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (baseStage.size() + finalStage.size() != samples)
|
|
|
|
qFatal("render_data: #samples does not add up to number of counted samples, file=%s", qPrintable(fileName));
|
|
|
|
|
|
|
|
QTest::newRow(qPrintable(fileName)) << fileName << baseStage << finalStage;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void tst_SceneGraph::render()
|
|
|
|
{
|
2020-06-10 07:26:52 +00:00
|
|
|
if (!isRunningOnRhi())
|
|
|
|
QSKIP("Skipping complex rendering tests due to not running with QRhi");
|
2016-05-06 10:48:04 +00:00
|
|
|
|
2013-10-31 21:22:54 +00:00
|
|
|
QFETCH(QString, file);
|
|
|
|
QFETCH(QList<Sample>, baseStage);
|
|
|
|
QFETCH(QList<Sample>, finalStage);
|
|
|
|
|
|
|
|
QObject suite;
|
|
|
|
suite.setObjectName("The Suite");
|
|
|
|
|
|
|
|
QQuickView view;
|
|
|
|
view.rootContext()->setContextProperty("suite", &suite);
|
2016-08-03 18:01:58 +00:00
|
|
|
view.setSource(testFileUrl(file));
|
2013-10-31 21:22:54 +00:00
|
|
|
view.setResizeMode(QQuickView::SizeViewToRootObject);
|
|
|
|
view.show();
|
|
|
|
QVERIFY(QTest::qWaitForWindowExposed(&view));
|
|
|
|
|
2014-06-04 18:32:07 +00:00
|
|
|
// We're checking actual pixels, so scale up the sample point to the top-left of the
|
|
|
|
// 2x2 pixel block and hope that this is good enough. Ideally, view and content
|
|
|
|
// would be in identical coordinate space, meaning pixels, but we're not in an
|
|
|
|
// ideal world.
|
|
|
|
// Just keep this in mind when writing tests.
|
|
|
|
qreal scale = view.devicePixelRatio();
|
2023-03-14 12:59:03 +00:00
|
|
|
const bool isIntegerScale = qFuzzyIsNull(qreal(qFloor(scale)) - scale);
|
|
|
|
|
|
|
|
if (file == "render_OutOfFloatRange.qml" && !isIntegerScale)
|
|
|
|
QSKIP("render_OutOfFloatRange doesn't work with non-integer scaling factors");
|
2014-06-04 18:32:07 +00:00
|
|
|
|
2013-10-31 21:22:54 +00:00
|
|
|
// Grab the window and check all our base stage samples
|
|
|
|
QImage content = view.grabWindow();
|
|
|
|
for (int i=0; i<baseStage.size(); ++i) {
|
|
|
|
Sample sample = baseStage.at(i);
|
2014-06-04 18:32:07 +00:00
|
|
|
QVERIFY2(sample.check(content, scale), qPrintable(sample.toString(content)));
|
2013-10-31 21:22:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Put the qml file into the final stage and wait for it to
|
|
|
|
// complete it.
|
|
|
|
QQuickItem *rootItem = view.rootObject();
|
|
|
|
QMetaObject::invokeMethod(rootItem, "enterFinalStage");
|
|
|
|
QTRY_VERIFY(rootItem->property("finalStageComplete").toBool());
|
|
|
|
|
|
|
|
// The grab the results and verify the samples in the end state.
|
|
|
|
content = view.grabWindow();
|
|
|
|
for (int i=0; i<finalStage.size(); ++i) {
|
|
|
|
Sample sample = finalStage.at(i);
|
2014-06-04 18:32:07 +00:00
|
|
|
QVERIFY2(sample.check(content, scale), qPrintable(sample.toString(content)));
|
2013-10-31 21:22:54 +00:00
|
|
|
}
|
|
|
|
}
|
2013-10-17 12:53:33 +00:00
|
|
|
|
2016-11-16 13:22:36 +00:00
|
|
|
#if QT_CONFIG(opengl)
|
2013-11-18 07:53:13 +00:00
|
|
|
// Testcase for QTBUG-34898. We make another context current on another surface
|
|
|
|
// in the GUI thread and hide the QQuickWindow while the other context is
|
|
|
|
// current on the other window.
|
|
|
|
void tst_SceneGraph::hideWithOtherContext()
|
|
|
|
{
|
2020-06-10 07:26:52 +00:00
|
|
|
if (!isRunningOnRhi())
|
|
|
|
QSKIP("Skipping OpenGL context test due to not running with QRhi");
|
2017-08-30 12:39:28 +00:00
|
|
|
|
2013-11-18 07:53:13 +00:00
|
|
|
QWindow window;
|
|
|
|
window.setSurfaceType(QWindow::OpenGLSurface);
|
|
|
|
window.resize(100, 100);
|
|
|
|
window.create();
|
|
|
|
QOpenGLContext context;
|
2015-01-26 08:25:15 +00:00
|
|
|
QVERIFY(context.create());
|
2013-11-18 07:53:13 +00:00
|
|
|
bool renderingOnMainThread = false;
|
|
|
|
|
|
|
|
{
|
|
|
|
QQuickView view;
|
2016-08-03 18:01:58 +00:00
|
|
|
view.setSource(testFileUrl("simple.qml"));
|
2013-11-18 07:53:13 +00:00
|
|
|
view.setResizeMode(QQuickView::SizeViewToRootObject);
|
|
|
|
view.show();
|
|
|
|
QVERIFY(QTest::qWaitForWindowExposed(&view));
|
|
|
|
|
2020-06-10 07:26:52 +00:00
|
|
|
if (view.rendererInterface()->graphicsApi() != QSGRendererInterface::OpenGLRhi)
|
|
|
|
QSKIP("Skipping OpenGL context test due to not using OpenGL");
|
|
|
|
|
|
|
|
QOpenGLContext *ctx = static_cast<QOpenGLContext *>(view.rendererInterface()->getResource(
|
|
|
|
&view, QSGRendererInterface::OpenGLContextResource));
|
|
|
|
renderingOnMainThread = ctx->thread() == QGuiApplication::instance()->thread();
|
2013-11-18 07:53:13 +00:00
|
|
|
|
|
|
|
// Make the local context current on the local window...
|
|
|
|
context.makeCurrent(&window);
|
|
|
|
}
|
|
|
|
|
|
|
|
// The local context should no longer be the current one. It is not
|
|
|
|
// rebound because all well behaving Qt/OpenGL applications are
|
|
|
|
// required to makeCurrent their context again before making any
|
|
|
|
// GL calls to a new frame (see QOpenGLContext docs).
|
|
|
|
QVERIFY(!renderingOnMainThread || QOpenGLContext::currentContext() != &context);
|
|
|
|
}
|
2016-04-25 10:09:44 +00:00
|
|
|
#endif
|
2013-11-18 07:53:13 +00:00
|
|
|
|
2015-06-11 08:17:45 +00:00
|
|
|
void tst_SceneGraph::createTextureFromImage_data()
|
|
|
|
{
|
|
|
|
QImage rgba(64, 64, QImage::Format_ARGB32_Premultiplied);
|
|
|
|
QImage rgb(64, 64, QImage::Format_RGB32);
|
|
|
|
|
|
|
|
QTest::addColumn<QImage>("image");
|
|
|
|
QTest::addColumn<uint>("flags");
|
|
|
|
QTest::addColumn<bool>("expectedAlpha");
|
|
|
|
|
|
|
|
QTest::newRow("rgb") << rgb << uint(0) << false;
|
|
|
|
QTest::newRow("argb") << rgba << uint(0) << true;
|
|
|
|
QTest::newRow("rgb,alpha") << rgb << uint(QQuickWindow::TextureHasAlphaChannel) << false;
|
|
|
|
QTest::newRow("argb,alpha") << rgba << uint(QQuickWindow::TextureHasAlphaChannel) << true;
|
|
|
|
QTest::newRow("rgb,!alpha") << rgb << uint(QQuickWindow::TextureIsOpaque) << false;
|
|
|
|
QTest::newRow("argb,!alpha") << rgba << uint(QQuickWindow::TextureIsOpaque) << false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void tst_SceneGraph::createTextureFromImage()
|
|
|
|
{
|
|
|
|
QFETCH(QImage, image);
|
|
|
|
QFETCH(uint, flags);
|
|
|
|
QFETCH(bool, expectedAlpha);
|
|
|
|
|
|
|
|
QQuickView view;
|
2016-05-06 10:48:04 +00:00
|
|
|
view.show();
|
2018-02-21 08:16:14 +00:00
|
|
|
QVERIFY(QTest::qWaitForWindowExposed(&view));
|
2016-07-03 10:46:57 +00:00
|
|
|
QTRY_VERIFY(view.isSceneGraphInitialized());
|
2016-05-06 10:48:04 +00:00
|
|
|
|
2015-06-11 08:17:45 +00:00
|
|
|
QScopedPointer<QSGTexture> texture(view.createTextureFromImage(image, (QQuickWindow::CreateTextureOptions) flags));
|
|
|
|
QCOMPARE(texture->hasAlphaChannel(), expectedAlpha);
|
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
#if QT_CONFIG(vulkan)
|
|
|
|
static QVulkanInstance *TestOffscreenScene_vkinst = nullptr;
|
|
|
|
#endif
|
|
|
|
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
struct TestOffscreenScene
|
|
|
|
{
|
|
|
|
QQuickRenderControl *renderControl = nullptr;
|
|
|
|
QQuickWindow *window = nullptr;
|
|
|
|
QQmlEngine *engine = nullptr;
|
|
|
|
QQmlComponent *component = nullptr;
|
|
|
|
QQuickItem *rootItem = nullptr;
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
// to be called at the end of each test case once all TestOffscreenScene instances are destroyed
|
|
|
|
static void cleanup()
|
|
|
|
{
|
|
|
|
#if QT_CONFIG(vulkan)
|
|
|
|
delete TestOffscreenScene_vkinst;
|
|
|
|
TestOffscreenScene_vkinst = nullptr;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
~TestOffscreenScene()
|
|
|
|
{
|
|
|
|
delete component;
|
|
|
|
delete engine;
|
|
|
|
delete window;
|
|
|
|
delete renderControl;
|
|
|
|
}
|
|
|
|
};
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
static TestOffscreenScene *createOffscreenScene(const QUrl &url, QQuickWindow *compatibleWindow = nullptr)
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
{
|
2021-09-03 11:27:57 +00:00
|
|
|
std::unique_ptr<TestOffscreenScene> scene(new TestOffscreenScene);
|
|
|
|
scene->renderControl = new QQuickRenderControl;
|
|
|
|
scene->window = new QQuickWindow(scene->renderControl);
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
if (compatibleWindow) {
|
2021-09-03 11:27:57 +00:00
|
|
|
scene->window->setGraphicsApi(compatibleWindow->rendererInterface()->graphicsApi());
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
#if QT_CONFIG(vulkan)
|
|
|
|
if (compatibleWindow->rendererInterface()->graphicsApi() == QSGRendererInterface::VulkanRhi)
|
2021-09-03 11:27:57 +00:00
|
|
|
scene->window->setVulkanInstance(compatibleWindow->vulkanInstance());
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
QRhi *rhi = static_cast<QRhi *>(compatibleWindow->rendererInterface()->getResource(compatibleWindow, QSGRendererInterface::RhiResource));
|
|
|
|
if (rhi) {
|
|
|
|
// make it so that the rendercontrol will not create a new QRhi, but rather use what we specify here
|
2021-09-03 11:27:57 +00:00
|
|
|
scene->window->setGraphicsDevice(QQuickGraphicsDevice::fromRhi(rhi));
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
} else {
|
|
|
|
qWarning("No QRhi from the specified compatibleWindow, this is unexpected");
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
#if QT_CONFIG(vulkan)
|
2021-09-03 11:27:57 +00:00
|
|
|
if (QQuickWindow::graphicsApi() == QSGRendererInterface::Vulkan) { // honor what QSG_RHI_BACKEND says
|
|
|
|
if (!TestOffscreenScene_vkinst) {
|
|
|
|
TestOffscreenScene_vkinst = new QVulkanInstance;
|
|
|
|
TestOffscreenScene_vkinst->setExtensions(QQuickGraphicsConfiguration::preferredInstanceExtensions());
|
|
|
|
TestOffscreenScene_vkinst->create();
|
|
|
|
}
|
|
|
|
scene->window->setVulkanInstance(TestOffscreenScene_vkinst);
|
|
|
|
}
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
scene->engine = new QQmlEngine;
|
|
|
|
scene->component = new QQmlComponent(scene->engine, url);
|
|
|
|
if (scene->component->isError()) {
|
|
|
|
for (const QQmlError &error : scene->component->errors())
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
qWarning() << error.url() << error.line() << error;
|
2021-09-03 11:27:57 +00:00
|
|
|
return nullptr;
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
QObject *rootObject = scene->component->create();
|
|
|
|
if (scene->component->isError()) {
|
|
|
|
for (const QQmlError &error : scene->component->errors())
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
qWarning() << error.url() << error.line() << error;
|
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
scene->rootItem = qobject_cast<QQuickItem *>(rootObject);
|
|
|
|
if (!scene->rootItem) {
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
qWarning("No root QQuickItem");
|
2021-09-03 11:27:57 +00:00
|
|
|
return nullptr;
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
scene->window->contentItem()->setSize(scene->rootItem->size());
|
|
|
|
scene->window->setGeometry(0, 0, scene->rootItem->width(), scene->rootItem->height());
|
|
|
|
scene->rootItem->setParentItem(scene->window->contentItem());
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
if (!scene->renderControl->initialize()) {
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
qWarning("Failed to initialize rendercontrol");
|
2021-09-03 11:27:57 +00:00
|
|
|
return nullptr;
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
return scene.release();
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void tst_SceneGraph::withAdoptedRhi()
|
|
|
|
{
|
|
|
|
if (!isRunningOnRhi())
|
|
|
|
QSKIP("Skipping test due to not running with QRhi");
|
|
|
|
|
|
|
|
// Use only QQuickRenderControl-based, single-threaded scenes for this
|
|
|
|
// test. QQuickView would not be suitable because it it uses the threaded
|
|
|
|
// render loop, then we end up in threading issues with graphics resources.
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
TestOffscreenScene *scene1 = createOffscreenScene(testFileUrl(QLatin1String("renderControl_rect.qml")));
|
|
|
|
QVERIFY(scene1->renderControl && scene1->window && scene1->rootItem);
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
// Now another one, but this time sharing the same QRhi as the first one.
|
2021-09-03 11:27:57 +00:00
|
|
|
TestOffscreenScene *scene2 = createOffscreenScene(testFileUrl(QLatin1String("renderControl_rect.qml")), scene1->window);
|
|
|
|
QVERIFY(scene2->renderControl && scene2->window && scene2->rootItem);
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
QRhi *rhi = static_cast<QRhi *>(scene1->window->rendererInterface()->getResource(scene1->window, QSGRendererInterface::RhiResource));
|
|
|
|
QCOMPARE(rhi, static_cast<QRhi *>(scene2->window->rendererInterface()->getResource(scene2->window, QSGRendererInterface::RhiResource)));
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
{ // scope to get resources destroyed before the QRhi
|
2021-09-03 11:27:57 +00:00
|
|
|
const QSize size = scene1->rootItem->size().toSize();
|
|
|
|
QCOMPARE(size, scene2->rootItem->size().toSize());
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
QScopedPointer<QRhiRenderBuffer> ds(rhi->newRenderBuffer(QRhiRenderBuffer::DepthStencil, size, 1));
|
|
|
|
QVERIFY(ds->create());
|
|
|
|
|
|
|
|
// texture for scene1
|
|
|
|
QScopedPointer<QRhiTexture> tex1(rhi->newTexture(QRhiTexture::RGBA8, size, 1,
|
|
|
|
QRhiTexture::RenderTarget | QRhiTexture::UsedAsTransferSource));
|
|
|
|
QVERIFY(tex1->create());
|
|
|
|
QRhiTextureRenderTargetDescription rtDesc1(QRhiColorAttachment(tex1.data()));
|
|
|
|
rtDesc1.setDepthStencilBuffer(ds.data());
|
|
|
|
QScopedPointer<QRhiTextureRenderTarget> texRt1(rhi->newTextureRenderTarget(rtDesc1));
|
|
|
|
QScopedPointer<QRhiRenderPassDescriptor> rp1(texRt1->newCompatibleRenderPassDescriptor());
|
|
|
|
texRt1->setRenderPassDescriptor(rp1.data());
|
|
|
|
QVERIFY(texRt1->create());
|
2021-09-03 11:27:57 +00:00
|
|
|
scene1->window->setRenderTarget(QQuickRenderTarget::fromRhiRenderTarget(texRt1.data()));
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
// for scene2
|
|
|
|
QScopedPointer<QRhiTexture> tex2(rhi->newTexture(QRhiTexture::RGBA8, size, 1,
|
|
|
|
QRhiTexture::RenderTarget | QRhiTexture::UsedAsTransferSource));
|
|
|
|
QVERIFY(tex2->create());
|
|
|
|
QRhiTextureRenderTargetDescription rtDesc2(QRhiColorAttachment(tex2.data()));
|
|
|
|
rtDesc2.setDepthStencilBuffer(ds.data());
|
|
|
|
QScopedPointer<QRhiTextureRenderTarget> texRt2(rhi->newTextureRenderTarget(rtDesc2));
|
|
|
|
QScopedPointer<QRhiRenderPassDescriptor> rp2(texRt2->newCompatibleRenderPassDescriptor());
|
|
|
|
texRt2->setRenderPassDescriptor(rp2.data());
|
|
|
|
QVERIFY(texRt2->create());
|
2021-09-03 11:27:57 +00:00
|
|
|
scene2->window->setRenderTarget(QQuickRenderTarget::fromRhiRenderTarget(texRt2.data()));
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
// render a frame, first with scene1, then with scene2, targeting their respective textures
|
2021-09-03 11:27:57 +00:00
|
|
|
scene1->renderControl->polishItems();
|
|
|
|
scene1->renderControl->beginFrame();
|
|
|
|
scene1->renderControl->sync();
|
|
|
|
scene1->renderControl->render();
|
|
|
|
scene1->renderControl->endFrame();
|
|
|
|
|
|
|
|
scene2->renderControl->polishItems();
|
|
|
|
scene2->renderControl->beginFrame();
|
|
|
|
scene2->renderControl->sync();
|
|
|
|
scene2->renderControl->render();
|
|
|
|
scene2->renderControl->endFrame();
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
|
|
|
|
// Both tex1 and tex2 belong to the same one QRhi. Read back the
|
|
|
|
// contents. In a real world application one could now render with the
|
|
|
|
// QRhi to some other window, using both textures.
|
|
|
|
for (int stage = 0; stage < 2; ++stage) {
|
|
|
|
QRhiCommandBuffer *cb = nullptr;
|
|
|
|
rhi->beginOffscreenFrame(&cb);
|
|
|
|
bool readCompleted = false;
|
|
|
|
QRhiReadbackResult readResult;
|
|
|
|
QImage result;
|
|
|
|
readResult.completed = [&readCompleted, &readResult, &result, &rhi] {
|
|
|
|
readCompleted = true;
|
|
|
|
QImage wrapperImage(reinterpret_cast<const uchar *>(readResult.data.constData()),
|
|
|
|
readResult.pixelSize.width(), readResult.pixelSize.height(),
|
|
|
|
QImage::Format_RGBA8888_Premultiplied);
|
|
|
|
if (rhi->isYUpInFramebuffer())
|
|
|
|
result = wrapperImage.mirrored();
|
|
|
|
else
|
|
|
|
result = wrapperImage.copy();
|
|
|
|
};
|
|
|
|
QRhiResourceUpdateBatch *readbackBatch = rhi->nextResourceUpdateBatch();
|
|
|
|
readbackBatch->readBackTexture(stage == 0 ? tex1.data() : tex2.data(), &readResult);
|
|
|
|
cb->resourceUpdate(readbackBatch);
|
|
|
|
rhi->endOffscreenFrame();
|
|
|
|
|
|
|
|
QVERIFY(readCompleted);
|
|
|
|
QCOMPARE(result.size(), QSize(200, 200));
|
|
|
|
const int maxFuzz = 2;
|
|
|
|
// red
|
|
|
|
QVERIFY(qAbs(qRed(result.pixel(100, 100)) - 255) < maxFuzz);
|
|
|
|
QVERIFY(qAbs(qGreen(result.pixel(100, 100))) < maxFuzz);
|
|
|
|
QVERIFY(qAbs(qBlue(result.pixel(100, 100))) < maxFuzz);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-09-03 11:27:57 +00:00
|
|
|
delete scene2; // this does not destroy the QRhi
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
// call anything on the QRhi just to test if it is still valid
|
|
|
|
QVERIFY(!rhi->isDeviceLost());
|
2021-09-03 11:27:57 +00:00
|
|
|
delete scene1; // this does
|
|
|
|
|
|
|
|
TestOffscreenScene::cleanup();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void commitTexture(QRhi *rhi, QSGTexture *texture)
|
|
|
|
{
|
|
|
|
QRhiResourceUpdateBatch *rub = rhi->nextResourceUpdateBatch();
|
|
|
|
texture->commitTextureOperations(rhi, rub);
|
|
|
|
QRhiCommandBuffer *cb = nullptr;
|
|
|
|
rhi->beginOffscreenFrame(&cb);
|
|
|
|
cb->resourceUpdate(rub);
|
|
|
|
rhi->endOffscreenFrame();
|
|
|
|
}
|
|
|
|
|
|
|
|
void tst_SceneGraph::resizeTextureFromImage()
|
|
|
|
{
|
|
|
|
if (!isRunningOnRhi())
|
|
|
|
QSKIP("Skipping test due to not running with QRhi");
|
|
|
|
|
|
|
|
// We will need to directly work with QSGTexture and QRhi so have
|
|
|
|
// to be on the same thread as the scene graph. Hence using the
|
|
|
|
// offscreen infrastructure from other tests.
|
|
|
|
|
|
|
|
// note the lifetimes: (vulkan instance) > scenegraph(incl. QRhi) > QSGTexture
|
|
|
|
{
|
|
|
|
QScopedPointer<TestOffscreenScene> scene(createOffscreenScene(testFileUrl(QLatin1String("renderControl_rect.qml"))));
|
|
|
|
QVERIFY(scene->renderControl && scene->window && scene->rootItem);
|
|
|
|
|
|
|
|
{
|
|
|
|
QImage image(256, 128, QImage::Format_RGBA8888);
|
|
|
|
QScopedPointer<QSGTexture> texture(scene->window->createTextureFromImage(image, QQuickWindow::TextureHasAlphaChannel));
|
|
|
|
QRhi *rhi = static_cast<QRhi *>(scene->window->rendererInterface()->getResource(scene->window, QSGRendererInterface::RhiResource));
|
|
|
|
QVERIFY(rhi);
|
|
|
|
commitTexture(rhi, texture.data());
|
|
|
|
// neither is too big nor relies on optional features like NPoT repeat so the size should match always
|
|
|
|
QCOMPARE(texture->textureSize(), image.size());
|
|
|
|
QCOMPARE(texture->rhiTexture()->pixelSize(), image.size());
|
|
|
|
|
|
|
|
QSGPlainTexture *plainTex = qobject_cast<QSGPlainTexture *>(texture.data());
|
|
|
|
QVERIFY(plainTex);
|
|
|
|
|
|
|
|
// QTBUG-96190 - the commitTexture call here used to crash due to not
|
|
|
|
// updating the QRhiTexture size correctly in QSGPlainTexture.
|
|
|
|
image = QImage(512, 256, QImage::Format_RGBA8888);
|
|
|
|
plainTex->setImage(image);
|
|
|
|
commitTexture(rhi, texture.data());
|
|
|
|
QCOMPARE(texture->textureSize(), image.size());
|
|
|
|
QCOMPARE(texture->rhiTexture()->pixelSize(), image.size());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TestOffscreenScene::cleanup();
|
Make it possible to adopt an existing QRhi via QQuickGraphicsDevice
Just as QQuickRenderTarget allows with its (also \internal)
fromRhiRenderTarget to import (but not own) and existing
QRhiRenderTarget for a QQuickWindow, we can have the same for the QRhi
itself.
Having a fromRhi() in QQuickGraphicsDevice allows telling a
QQuickWindow to use an existing QRhi. This makes sense in particular
with QQuickRenderControl: one can now render two or more scenes (each
with its own QQuickWindow and QQuickRenderControl, but all using the
same QRhi under the hood) and then use the resulting textures with the
QRhi, because the QRhiTextures all belong to it to begin with.
While this is useful for applications in general, it is also an
enabler for modernizing QQuickWidget in the future, in case we choose
to do so.
Comes with an autotest case that, besides testing, is also a
demonstration of the feature. Once an application has rendered a frame
with the same QRhi from all the Qt Quick scenes, it can go on to do
something with the textures (e.g. compose them together in some other
window) because both belong to the same one QRhi.
Note that this comes with certain limitations, similarly to
QQuickGraphicsDevice::fromOpenGLContext. (the docs are noting this for
both functions now) For example, one cannot just pull out a QRhi from
under an on-screen QQuickWindow or QQuickView and expect it to be
usable in all cases, without limitations. For example, if the threaded
render loop is in use, using the QRhi extracted from the QQuickView is
a very bad idea. However, in the common QQuickRenderControl-based
cases this is not an issue because there one would render frames from
the (offscreen) QQuickWindows one by one on the same thread.
Change-Id: I91b8b1f11f1cb4a84824c47d3b1d4f31833dd61b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-08-26 16:00:21 +00:00
|
|
|
}
|
|
|
|
|
Add the graphics api independent scenegraph port
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-04-23 07:40:59 +00:00
|
|
|
bool tst_SceneGraph::isRunningOnRhi()
|
2017-08-30 12:39:28 +00:00
|
|
|
{
|
Add the graphics api independent scenegraph port
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-04-23 07:40:59 +00:00
|
|
|
static bool retval = false;
|
|
|
|
static bool decided = false;
|
|
|
|
if (!decided) {
|
|
|
|
decided = true;
|
|
|
|
QQuickView dummy;
|
|
|
|
dummy.show();
|
|
|
|
if (!QTest::qWaitForWindowExposed(&dummy)) {
|
|
|
|
[](){ QFAIL("Could not show a QQuickView"); }();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
QSGRendererInterface::GraphicsApi api = dummy.rendererInterface()->graphicsApi();
|
|
|
|
retval = QSGRendererInterface::isApiRhiBased(api);
|
|
|
|
dummy.hide();
|
2019-06-10 23:01:10 +00:00
|
|
|
}
|
2017-08-30 12:39:28 +00:00
|
|
|
return retval;
|
|
|
|
}
|
2013-11-18 07:53:13 +00:00
|
|
|
|
2013-10-17 12:53:33 +00:00
|
|
|
#include "tst_scenegraph.moc"
|
|
|
|
|
|
|
|
QTEST_MAIN(tst_SceneGraph)
|
|
|
|
|