As well as the MACOSX_BUNDLE properties as necessary.
Task-number: QTBUG-87664
Task-number: QTBUG-86827
Change-Id: I46769fb543acb2cbeba122470b5e44ad478fbe4e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Replace more QLibaryInfo::location with QLibraryInfo::path
Replace old event accessors APIs, including relevant comments.
Change-Id: Ie205fc93b6e1c0dfb3dca9100fbde417ab68fc9f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
They are not strictly related of course, but the API pattern should be
kept. We can also move away from the QSGTexture dependency which is good
since that was never directly related.
Change-Id: I9aedff5918443bda3d6e3ee1ea389071222d1ad7
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
...and fix up the docs.
The string-based setSceneGraphBackend() stays of course (the docs have
been enhanced, however). The GraphicsApi enum-based overload is now
renamed to setGraphicsApi().
Using the same name for both functions is a historical artifact, reflecting
the evolution (5.0 - 5.8 - 5.14). In 6.0 we can give it a more appropriate
name, since it does not have much to do with "backends" from the user's
perspective.
Change-Id: Id75dbf81f50a148797e5b5de9be4000153737473
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
QQuickWindow should not have OpenGL specifics in its API in Qt 6.
However, resetOpenGLState() is used by applications commonly in
combination with QQuickFramebufferObject (not the least because the
documentation recommends it!). This is no problem in practice because
QQuickFramebufferObject remains an OpenGL-only feature. So to minimize
the breaks, move the function into QQuickFramebufferObject::Renderer so
any application that calls the function can continue to do so by just
calling it on 'this' instead.
The rendercontrol_opengl example used to call this function as well, but
unnecessarily, it will still function the same way without it.
Note that there is a chance that there are applications that call
resetOpenGLState() in other contexts, for example in slots connected to
before or afterRendering(). For these it will need to be determined if
the call is necessary at all, and if it is, should be replaced by
(re)setting the appropriate OpenGL state manually instead.
Task-number: QTBUG-84523
Change-Id: I335599f77e8a84e347a44427eb1a1bf917796ee8
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Includes
- new example installation paths
- one case of QT_QMLTYPES_FILENAME addition
Change-Id: I24423da9b04b6ecc8445017fa35f148dd43b1829
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
We will not invest into adding workarounds in the example code
as the boilerplate to keep such unofficial environments working is
not worth the effort and compromises readability in example code.
Just skip building on MinGW.
Change-Id: If33bd0382f8cab4713ad45fcaa126830e9760af3
Reviewed-by: Liang Qi <liang.qi@qt.io>
To make the API less error prone, we have changed the
void pointer to the texture handle to a 64-bit in
instead, since all handles are maximum 64-bit.
Task-number: QTBUG-78638
Change-Id: I9d995d6a883b3377f57d7c5b19d4bc4e15aa347b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Make it work when using QRhi-on-OpenGL.
Some features like demonstrating a dedicated render thread, or targeting
the window with the Quick content ('onscreen' argument, not clear why
that was added in the first place), are now removed. Some of these could
be reintroduced in future examples, not necessarily in combination with
OpenGL. For now they are removed since the cost of porting and
maintaining all that is not reasonable at this point.
Task-number: QTBUG-84040
Change-Id: I67e5c7cc835c5cf5653cf827004ce66a4d300b36
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
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>
Joerg Bornemann
Laszlo Agocs
Craig Scott
Alexandru Croitor
Volker Hilsheimer
Shawn Rutledge
Oliver Wolff
Eskil Abrahamsen Blomfeldt
Leander Beernaert
Paul Wicking
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