Implement the Qt 6 TODO for using an externally-provided render target
when rendering the scene via QRhi.
And say hello to QQuickRenderTarget. This class exists to allow
potentially extending later what a "render target" consists
of. Instead of hard-coding taking a single void * in the
setRenderTarget() function, it takes a (implicitly shared,
d-pointered) QQuickRenderTarget, which in turn can be created via
static factory functions - of which new ones can be added later on.
The new version of QQuickWindow::setRenderTarget() takes a
QQuickRenderTarget.
QQuickRenderControl gets a new initialize() variant, and a few extra
functions (beginFrame(), endFrame()). This allows it to, by using
QSGRhiSupport internally, create a QRhi under the hood.
As a bonus, this also fixes an existing scenegraph resource leak when
destroying the QQuickRenderControl.
The qquickrendercontrol autotest is extended, with a QRhi-based test
case that is executed for all of the QRhi backends that succeed to
initialize. This is the internal verification. In addition, there is
a Vulkan-based one that creates its own VkDevice, VkImage, and
friends, and then uses Qt Quick with the same Vulkan device, targeting
the VkImage. This test verifies the typical application use
case. (sadly, life is too short to waste it on writing Vulkan
boilerplate for an on-screen version of this, but we have the D3D11
example instead)
What QQuickRenderControl loses, when used in combination with QRhi, is
the grab() function. This never made much sense as a public API:
QQuickWindow::grabWindow() call this when the window is associated
with a rendercontrol, so as a public API QQuickRenderControl::grab()
is redundant, because one gets the same result via the standard
QQuickWindow API. It is now made private.
More importantly, reading back the content is no longer supported,
unless the 'software' backend is in use. The reasoning here is that,
if the client of the API manages and provides the render target (as
abstracted by QQuickRenderTarget), it is then expected to be capable
of reading back the content in whatever way it sees fit, because it
owns and manages the resource (e.g. the texture) in the first
place. Providing fragile convenience functions for this is not
reasonable anymore, and was questionable even with OpenGL, given that
it is not future proof - what if the target is suddenly a floating
point texture, for instance? The software backend case makes sense
because that relies on private APIs - and has no render target concept
either - so there the same cannot be achieved by applications by
relying on public APIs only.
Another new class is QQuickGraphicsDevice. This is very similar to
QQuickRenderTarget, it is a simple container capable of holding a set
of of native objects, mostly in the form of void*s, with future
extensibility thanks to the static factory functions. (examples of
native object sets would be a ID3D11Device + ID3D11DeviceContext, or a
QOpenGLContext, or a MTLDevice + MTLCommandQueue, or a number of
Vulkan device-related objects, etc.) This allows one to specify that
the QRhi created under the hood (either by QQuickRenderControl or by
the render loop) should use an existing graphics device (i.e. it is
basically a public wrapper for values that go into a QRhi*InitParams
under the hood).
QQuickRenderTarget and QQuickGraphicsDevice are both demonstrated in a
new example: rendercontrol_d3d11. We choose D3D11 because it is
reasonably simple to set up a renderer with a window, and, because
there is known user demand for Qt Quick - external D3D engine
interop. Passing in the custom engine's own ID3D11Device and
ID3D11DeviceContext is essential: the texture (ID3D11Texture2D) Qt
Quick is targeting would not be usable if Qt Quick's QRhi was using a
different ID3D11Device.
Task-number: QTBUG-78595
Change-Id: I5dfe7f6cf1540daffc2f11136be114a08e87202b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
...called rendercontrol_opengl under examples/quick/rendercontrol. This
example is going to be migrated to support operating with RHI-on-OpenGL
later on.
Additionally, we can this way introduce more rendercontrol examples in
the future, for example to show how to do things with Vulkan, Metal,
D3D.
Task-number: QTBUG-78595
Change-Id: I7f5243b1f86e62949400107bf12bfa07b17b1031
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
This patch converts all examples in qtdeclarative except for a few
exceptions which require a public facing qml plugin api.
Change-Id: I2cd2b1bb455be8b48796893a8235dea7f8b35aa2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
...in QQuickWindow::setRenderTarget().
The rendercontrol example is extended with a --onscreen
command line argument that can be used to request rendering
to the default framebuffer of the window.
Change-Id: I7a500d1585dee8334b902fb1dddcb1cb21a2e038
Task-number: QTBUG-59340
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
While touching the code, replace QStringLiteral
with QL1S in QStringBuilder expression.
Change-Id: I2519b254d82453e1c9bd5b834c0bd78e5c026f83
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
From Qt 5.7 -> examples are lisenced under BSD license, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new BSD header instead of LGPL21 one
(in those files which will be under BSD)
Change-Id: I09ba19590e9425d5116a6c27cbc183debb485dde
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
renderWindow() was not reimplemented in the example. This is pretty
bad since renderWindowFor() fails to find a window and thus falls
back to using the default device pixel ratio (which is the highest
dpr present in the system). The result is broken content from Quick
because it operates with a dpr of 2 any time a retina screen is connected,
even when the example's own QWindow is placed on a normal screen.
Add also a note to the QQuickRenderControl docs because it is easy to
overlook.
Task-number: QTBUG-45613
Change-Id: I31bf92ec285f3d9867a5604a4b4e3bea73791932
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Even when the window size is not changing. This provides a useful
example of connecting to the screenChanged() signal.
Task-number: QTBUG-45613
Change-Id: I0652838d9c0cfec8b64b3422997159f385445b20
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
The threaded variant was working well since that triggers a render
when resizing. The single threaded version lacked this and this
resulted in showing garbage on OS X at least since the new FBO had
undefined contents. Avoid this.
Task-number: QTBUG-45613
Change-Id: Ibb3d3f7640bab5da913df1c0c63cc3a3aaafb140
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
In the multithreaded case we attempted to create QWindows outside
the gui thread on platforms where QOffscreenSurface is backed by
the hidden QWindow in the absence of a better solution. This has
to be avoided. Therefore, pass a suitable surface from the gui
thread instead.
This will avoid "Attempting to create QWindow-based QOffscreenSurface
outside the gui thread." type of warnings when running on OS X with
--threaded.
Change-Id: Ie3ebeeeaa9e6bdf83e763e40213e2940fbfde667
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
Otherwise we will show broken output with some drivers.
QQuickWidget does this already.
Change-Id: I5193595c4606d0497dbe85f6f8c670618ca366e9
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
Reorganize the rendercontrol example to demonstrate both the single
and multi threaded approaches.
A small helper function is introduced to the QQuickRenderControl API:
The QSGRenderContext has to live on the render thread. Previously there
was no way for applications to move it to the desired thread. This is
now possible.
Pass --threaded to the rendercontrol example to use a separate render thread.
[ChangeLog][QtQuick] QQuickRenderControl can now be used to render the Qt Quick
scene on a dedicated render thread, similarly to how the built-in threaded render
loop operates.
Task-number: QTBUG-42813
Change-Id: I01c3b2ffca8a174d9d2c267a51f2e484ed7b34b3
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
QQuickRenderControl allows rendering Qt Quick 2 scenes into framebuffer
objects which can then be used in arbitrary ways in Qt-based or 3rd party
OpenGL renderers.
[ChangeLog][QtQuick] Introduced QQuickRenderControl as a public API.
Task-number: QTBUG-37944
Change-Id: I84262243b261b35cefdf67ec6bba8127a0f29275
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Laszlo Agocs
Leander Beernaert
Paul Wicking
Shawn Rutledge
Liang Qi
Friedemann Kleint
Kai Koehne
Kevin Funk
Anton Kudryavtsev
Liang Qi
Jan Arve Saether
Jani Heikkinen
Friedemann Kleint
Laszlo Agocs
Holger Hans Peter Freyther
Laszlo Agocs
Jani Heikkinen