aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickrendercontrol.h
Commit message (Collapse)AuthorAgeFilesLines
* Remove superfluous include directiveFriedemann Kleint2021-02-021-1/+0
| | | | | | | | | | | It is not conforming to the include conventions (module missing) and thus breaks the Qt for Python doc build. Introduced by 48b4c1f450109b148f03f62574d78b460859c4a1. Pick-to: 6.0 Change-Id: I1ff56a967c457f1909b7f6e2e430458e3a3f47c9 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make sure that header is self-containedKai Koehne2020-08-261-0/+1
| | | | | | | | | Since qtbase commit f741a12de11c9 qimage.h doesn't include qobject.h anymore. Task-number: QTBUG-82615 Change-Id: I9422bcc049bc34271c91e341017881a18857d155 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Adapt to qtbase changesFabian Kosmale2020-08-231-0/+1
| | | | | | | | | | | The internal QVariant constructor taking a QMetaTypeId has been removed. Thus, construct QMetaTypes where necessary from the id, or avoid a QMetaType -> ID -> QMetaType roundtrip where we already have a metatype. Also fix a few missing includse that were previously transitively included. Change-Id: I56ce92281d616108a4ff80fe5052b919d1282357 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
* Make render loops OpenGL cleanLaszlo Agocs2020-06-081-1/+0
| | | | | | | Task-number: QTBUG-84718 Task-number: QTBUG-84623 Change-Id: I14392c365a52ecc410362500bbe29b4dd7953007 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Allow redirecting QRhi-based rendering via QQuickRenderControlLaszlo Agocs2020-04-111-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* use the override keyword consistently and correctly (clang-tidy)Shawn Rutledge2018-02-271-1/+1
| | | | | Change-Id: If9e28d143f8cba3df3c757476b4f2265e2eb8b2a Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* Replace Q_NULLPTR with nullptrKevin Funk2017-09-271-3/+3
| | | | | Change-Id: I0c01862dbb475494c84e39c695cb563df8cbcfa8 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-03-071-3/+3
|\ | | | | | | Change-Id: Icfa1d61fcc286c3418d4a625de11d2191336fa60
| * Make more ctors explicitMarc Mutz2016-03-031-1/+1
| | | | | | | | | | | | | | | | | | Added explicit where it was missing. This is not a source- incompatible change, because code that breaks by this is a bug. Let's not have this sitting around in an LTS. Change-Id: Ic198750717799126b4e37817845a8ee4684d631f Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
| * Make public headers compile with -Wzero-as-null-pointer-constantMarc Mutz2016-03-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | ... or equivalent. QtBase 5.6 headers already compile that way, so let the other modules follow suit. Task-number: QTBUG-45291 Change-Id: Ied526fb2d7adc3a68946d6843a6bd6f475ebf864 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* | Updated license headersJani Heikkinen2016-01-191-14/+20
|/ | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-121-7/+7
| | | | | | | | | 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>
* Support threading with QQuickRenderControlLaszlo Agocs2014-12-121-0/+2
| | | | | | | | | | | | | | | | | | | | | 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>
* Update license headers and add new licensesJani Heikkinen2014-08-251-18/+10
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 & LICENSE.GPLv2 - Removed LICENSE.GPL Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0 Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
* Rename QQuickRenderControl::stop() to invalidate()Laszlo Agocs2014-08-071-1/+1
| | | | | | | To be consistent. Change-Id: Ia78bf4a27e8ccb1a4f0a44865e810f1070c39e5d Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
* Make QQuickRenderControl publicLaszlo Agocs2014-06-241-0/+84
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 12:39:06 +0000