aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickrendercontrol.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/tqtc/lts-6.2.8' into ↵Tarja Sundqvist2024-02-201-2/+2
|\ | | | | | | | | | | | | | | | | tqtc/lts-6.2-opensource Conflicts solved in a file: dependencies.yaml Change-Id: Ib4083daa41a689b937d2aeb522e93e3aab0be1c4
| * Doc: Fix typoAndreas Eliasson2022-12-131-2/+2
| | | | | | | | | | | | | | | | Fixes: QTBUG-107492 Change-Id: I3f5ad0421bbd0822c76c5e32e42616461cde31c3 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> (cherry picked from commit 39e584f31e60c3b4e7cc7a26d2a09ce36dad8eab) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* | Merge remote-tracking branch 'origin/tqtc/lts-6.2.7' into ↵Tarja Sundqvist2023-10-031-1/+1
|\| | | | | | | | | | | tqtc/lts-6.2-opensource Change-Id: Ib72ded968b7ac6b75b499392162e3cf3b761ec48
| * Make QSGRhiShaderEffectMaterial::type() safe with multiple windowsLaszlo Agocs2022-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The history of this mechanism goes back to early 5.0 days probably, when the case of showing multiple QQuickWindows was not always considered. Using a single data storage is not only unsafe when it comes to threading (if using the threaded render loop), but seems to cause visible rendering errors if certain conditions are met. (the problem is not strictly caused by emptying the list of QSGMaterialType pointers when a window goes away, that's safe in itself, but rather there is a chance of collisions then if 'new' gives the same pointer afterwards, breaking the uniqueness contract; or something along those lines) This is now solved by locking and making the storage per window, using the QQuickWindow as the key. Fixes: QTBUG-107818 Change-Id: I4f94c4bccb43c4db246aff02e0b809cc9f106e39 Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit d7d44783cee166e0dd0c24b56478ab6d4c0c6cdc) Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | Revert "Update commercial license headers"Tarja Sundqvist2022-11-241-21/+21
|/ | | | | | | | | | | This reverts commit 74089697cf2a4961fb697100555b17ae2342d734. Revert of commercial license headers is required for the Qt 6.2.x opensource releases, Qt 6.2.5 onwards. Task-number: QTBUG-107760 Change-Id: Id49069cb5e5f261da185fd082dfb71deb259d387 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Update commercial license headersTarja Sundqvist2022-06-041-21/+21
| | | | | | | | | | | | | | | Updated header.COMM to the files in tqtc-qtdeclarative. Examples, tests, or documentation files are not updated. The commercial license header may contain some additional lines so that its line count equals with the earlier license header. Reason for this is that some autotests use hard coded line numbers and a change in the line count causes failures in tests. Task-number: QTQAINFRA-4941 Change-Id: I32f554b0a8cb527f74d46f3c02b0e745d9fc5ddf Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix tracking of sg initialized state in rendercontrolLaszlo Agocs2022-02-221-0/+1
| | | | | | | | | | | | | | | The initialized = true statement either went missing or it never was there. This has zero effect on the common usage where the client does not bother with invalidate(), but rather destroys the QQuickRenderControl. However, more complex usages, such as in QQuickWidget do need to invalidate for various reasons, without destroying the entire QQuickRenderControl. Change-Id: Iaabc6309cb42cfdd624321863a5504cdeb01275d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit 167b22c7010363275f2895ff4965529b35c36eac) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix focus for items inside a QQuickWidget in a QGraphicsProxyWidgetPaul Olav Tvete2021-12-071-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | QQuickWidgetRenderControl::renderWindowFor() did not take the proxy widget into account, making it impossible to give focus to items inside a QGraphicsProxyWidget by clicking on the item. This patch is based on a patch by Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>, which fixed renderWindowFor(), but did not handle the case where a proxy widget was in multiple views. This version of the patch adds QQuickRenderControlPrivate::isRenderWindowFor(), which allows all the views of the proxy widget to handle focus. This patch also carefully preserves the non-obvious feature of the previous implementation where all windows are considered to have focus if QGuiApplication::focusWindow() == nullptr. [ChangeLog][QuickWidget][Quick items inside a QuickWidget that is inside a QGraphicsProxyWidget can now get focus by clicking.] Fixes: QTBUG-91479 Change-Id: I4a6fbbbeda2d14b5a6d8eb8218d5b14a3404d9c3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 8c0b1e06d9679676d12ff92db981198077eeda76) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Enhance QQuickRenderControl docs regarding key eventsLaszlo Agocs2021-06-151-5/+15
| | | | | | | | | | | ...and rephrase one of the general description paragraphs to be more accurate. Fixes: QTBUG-93489 Change-Id: If238fff84480720a618c8a337fe416cd08ee9b79 Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit 6dfed1ee9c8e03780b222a71f6b90fe2016d8994) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add env.vars. to toggle pipeline cache load/saveLaszlo Agocs2021-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QRhi has APIs (but private ones) that allow retrieving and restoring the contents of the "pipeline cache". (which may map directly to VkPipelineCache, or may be a simulated, OpenGL program binary based solution) In many cases it is convenient if the saving of the cache blob to a file, and then, during subsequent runs of the application, the loading of cache contents, can be enabled via environment variables: QSG_RHI_PIPELINE_CACHE_SAVE=filename maps to setting the EnablePipelineCacheDataSave flag on the QRhi, and writing the collected data to file upon application exit. (more correctly, when the QRhi is about to be destroyed by the render loop) QSG_RHI_PIPELINE_CACHE_LOAD=filename maps to attempting to read the contents of the specified file, and, if successful, passing it to QRhi right after initialization. When supported and the data is not corrupt or incomplete, the result is likely improved pipeline creation times (the exact details depend on the driver with Vulkan, while with OpenGL it all maps to glProgramBinary instead of compiling from source) Setting QSG_INFO=1 can be useful to see what is happening when the above 2 env.vars. are set. With OpenGL the simulated "pipeline cache" is orthogonal to the Qt 5 era shader program disk cache: loading from both is supported transparently to the application. When QSG_RHI_PIPELINE_CACHE_SAVE is enabled, the disk cache will not be written to. Task-number: QTBUG-90398 Change-Id: I82d9a81e9dab39d3513a6aa7c6e1ff748a4ec6e5 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Expose the list of preferred instance extensions to rendercontrol usersLaszlo Agocs2021-01-211-5/+8
| | | | | | | | | As all QRhi stuff is private, it needs to have a public counterpart in Qt Quick in order to fully support the case of Vulkan-based QQuickRenderControl usage. Change-Id: Iaf9a7aa56022acd31af6ebf16de6b83a04966ff4 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Fix documentation warnings for Qt QuickTopi Reinio2020-11-051-0/+2
| | | | | | | | | | | - Remove links to modules and examples that are not part of Qt 6. - Remove links to entities marked as \internal - Add missing enum value and QML property docs where it's trivial to do so. Task-number: QTBUG-88156 Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Follow rhi per-frame to per-pass flag changeLaszlo Agocs2020-10-051-1/+1
| | | | | Change-Id: I728cecd85807eb835703a0bb8bb4acdb1f2068ae Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Capitalize "GUI" correctlySze Howe Koh2020-08-301-1/+1
| | | | | | Pick-to: 5.15 Change-Id: I2230e2dcb7bc2497b5dbe71a22c21d84176b5e57 Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
* Rename setSceneGraphBackend to setGraphicsApiLaszlo Agocs2020-06-221-1/+1
| | | | | | | | | | | | | | | | ...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>
* Make it possible to specify device extensions in a future proof mannerLaszlo Agocs2020-06-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow the pattern of QQuickRenderTarget and QQuickGraphicsDevice. This makes it possible to integrate with real world frameworks, such as OpenXR, that, especially with Vulkan, expect this level of configurability. (i.e. one pulls the list of extensions to be enabled on the device, that then needs to be taken into account by Quick, otherwise it will end up with a VkDevice that is not usable by OpenXR) Same goes when integrating native Vulkan rendering into an application: if certain extensions need to be enabled on the VkDevice, today that can only be done with an environment variable which is not entirely ideal. These issues are now solved by a new simple (and extensible) container QQuickGraphicsConfiguration, which is associated with the QQuickWindow. When applicable, the scene graph will then pick up the relevant settings. Expand the related docs everywhere. Also rename the vulkanInstance() to defaultVulkanInstance() to emphasize that it is the instance that is used for normal QQuickWindows, and is not provided when redirecting via QQuickRenderControl. While we are at it, include another obvious candidate: the use-depth-buffer flag. It turns out that Quick3D's Overlay render mode can be pretty problematic if Quick writes to the depth buffer. In order to avoid relying on environment variables (QSG_NO_DEPTH_BUFFER), we now provide a proper API for controlling that as well. Change-Id: Iefdb62c1f53de8bd34e3f0d393b00c5020d6188a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Clean up QT_CONFIG(opengl)Paul Olav Tvete2020-06-171-5/+1
| | | | | | | | | | Accelerated graphics is now possible without OpenGL support. With this change, a Qt build with -no-opengl can still run Qt Quick with a Vulkan, Metal, or Direct3D backend. Fixes: QTBUG-84027 Change-Id: Ib63c733d28cfdf7de16b138df136fa7628e1747b Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix up QQuickRenderControl class docsLaszlo Agocs2020-06-121-17/+20
| | | | | | | | This was not updated together with the Qt 6 changes (the function docs are up-to-date already), do it now. Change-Id: I93c59df141a69d9943d1a3d88fe3a56fe6c096df Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Rename setPersistentOpenGLContext and revise related docsLaszlo Agocs2020-06-111-1/+1
| | | | | | | | | | | | | | | | | | These persistent hints are still taken into account by the threaded render loop, so keep them, but get rid of "OpenGL Context" from the function names. The qquickwindow autotest has been updated accordingly, and with a few OpenGL-related cleanups it now runs without any warnings or skips with OpenGL-on-RHI, while it skips only 1 case when running with some other API, and 2 with the software backend. [ChangeLog][Qt Quick][QQuickWindow] The setPersistentOpenGLContext() and isPersistentOpenGLContext() functions are renamed to setPersistentGraphics() and isPersistentGraphics(). Change-Id: Ifc4cc7c4b94fe9f7e402b39ca4f28952dcafd588 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QSGRhiShaderEffectNode is available only with openglSamuli Piippo2020-06-101-2/+3
| | | | | | | Fixes build without opengl Change-Id: Ica5752c21567b730065ec6276a9016b3989f9d02 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Make render loops OpenGL cleanLaszlo Agocs2020-06-081-65/+0
| | | | | | | Task-number: QTBUG-84718 Task-number: QTBUG-84623 Change-Id: I14392c365a52ecc410362500bbe29b4dd7953007 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove QQuickOpenGLShaderEffectPaul Olav Tvete2020-06-041-8/+4
| | | | | | | | | This also removes QQuickUniformAnimator, which is not yet ported to RHI (QTBUG-83976) Task-number: QTBUG-83977 Change-Id: I3e656e6817ac991371b7f6557f050e122635d279 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Adapt to changes in NativeTexture in qtbaseEskil Abrahamsen Blomfeldt2020-05-251-1/+1
| | | | | | | | | | 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>
* Fix build without openglSamuli Piippo2020-05-061-2/+3
| | | | | | | | The default backend code still depends on OpenGL: qquickrendercontrol.cpp: undefined reference to `QSGDefaultRenderContext::staticMetaObject' Change-Id: I7857f28f6ce8997dd38119c1d367d8cdbb3cbf37 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add beforeFrameBegin() and afterFrameEnd() to QQuickWindowLaszlo Agocs2020-04-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New additions to the QQuickWindow signal family. Out of the three stages of the (modern) frame generation process, only two are covered by the existing beforeRendering, beforeRenderPassRecording - afterRenderPassRecording, afterRendering pairs. With the new ones, the rendering of a simple Qt Quick scene looks like the following: emit beforeFrameBegin QRhi::beginFrame() emit beforeRendering ... (additional render passes targeting textures when layers or View3D are involved) QRhi::beginPass() emit beforeRenderPassRecording ... emit afterRenderPassRecording QRhi::endPass() emit afterRendering QRhi::endFrame() emit afterFrameEnd This fits very well the revised QQuickRenderControl API, which has explicit beginFrame-endFrame points as well. So now we can make both QQuickRenderControl and the render loops to emit these signals at the appropriate points. Task-number: QTBUG-83883 Change-Id: Ib385b29393f3b39b0700432d14ea3976cf337fa0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Allow redirecting QRhi-based rendering via QQuickRenderControlLaszlo Agocs2020-04-111-33/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Introduce new mechanism to manage palette functionality in QMLVitaly Fanaskov2020-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Main goals of these changes: 1) Add an ability to work with disabled and inactive palettes from QML 2) Eliminate massive code duplication in qtquickcontrols2 module 3) Provide easily extensible architecture for this piece of functionality Architectural part. Palette It was decided to not change existing QPalette, but add thin wrappers around it to provide all required functionality. These wrappers are highly coupled with QPalette class because of using some enum values from it. There are two new classes QQuickPalette and QQuickColorGroup. QQuickPalette class inherits QQuickColorGroup class and represents Active/All color group. QQuickPalette also provides an access to three color groups: Active, Inactive, and Disabled. In order to access colors the special class QQuickPaletteColorProvider is used. This is a wrapper around QPalette that provides some convenience functions. Interface The private property "palette" should be exposed. Implementation All private parts of classes that implement QQuickAbstractPaletteProvider have to inherit QQuickPaletteProviderPrivateBase class. This template class implement all functionality: create palette, resolve dependencies, connect objects etc. This is important to mention that related data is lazily allocatable on demand only. Hence, there is no memory overhead for regular items. Change-Id: I911424b730451b1ad47f68fd8007953b66eddb28 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Quick: Don't qualify OpenGL includes (part two)Johan Klokkhammer Helsing2020-02-181-1/+1
| | | | | | | | | | | | 406f15ce0e only removed the "QtGui" prefix from some includes, but we are trying to move (almost) everything OpenGL related from QtGui. This removes prefixes for additional QOpenGL includes (QOpenGLShaderProgram, versioned opengl functions etc.). Task-number: QTBUG-74409 Change-Id: I91e1feac0676859f11de9b75301a0a4e81db50d9 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-10-101-0/+1
|\ | | | | | | | | | | | | | | Conflicts: src/plugins/scenegraph/openvg/qsgopenvgcontext.cpp tests/auto/quick/qquickpathview/tst_qquickpathview.cpp Change-Id: I117c8d62b21800329d1035021d312d9924f83a1b
| * Fix QQuickWindow::afterAnimating with QQuickRenderControlPaul Lemire2019-10-101-0/+1
| | | | | | | | | | | | | | | | emits QQuickWindow::afterAnimating prior to synching changes Task-number: QTBUG-79084 Change-Id: Ie79d3b8ec912c2e662b2c0745dda442d47d184bd Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | QQuickWindow: Don't leak the animation controllerUlf Hermann2019-10-021-2/+1
| | | | | | | | | | | | | | | | | | There are ways to close the window without hitting the code paths in the render loops that delete the animation controller. Probably if no frame was ever rendered. Change-Id: If3e9d2051525c4ff50eda19084c967578fe4f4b0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Add the graphics api independent scenegraph portLaszlo Agocs2019-07-041-1/+12
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix null pointer access in QQuickOpenGLShaderEffectMaterialCacheJüri Valdmann2018-11-071-1/+2
| | | | | | | | | | | If a QQuickWindow is destroyed without ever being rendered, then there won't be any QOpenGLContext in QQuickOpenGLShaderEffectMaterial::cleanupMaterialCache. Same goes for QQuickWidgetRenderControl. Fixes: QTBUG-65236 Change-Id: I2742505d147bc8444b46688170d33fbb2844f2ac Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix QQuickRenderControl::invalidate with software rendererAllan Sandfeld Jensen2018-10-101-3/+3
| | | | | | | | | | With the software renderer QQuickRenderControl::initialize() is never called, but we still need to cleanup scenegraph nodes on destruction or invalidation. Change-Id: I4c17a440d683b1f0512fb8a9370430cf3680d8ee Task-number: QTBUG-70740 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Make QtDeclarative work for the no-thread configMorten Johan Sørvig2018-09-051-0/+2
| | | | | | | | | | | | | Force use of the basic render loop, adapt qqmlthread and qqmltypeloader to work on a single thread. Disable components and features that require worker threads: qmldb_server, worker script, shapes, folderlistmodel, threaded render loop, software renderer. Done-with: Lorn Potter <lorn.potter@gmail.com> Change-Id: I77d965947f684f8b7d19284b5decd893395316cb Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-07-161-1/+2
|\ | | | | | | | | | | | | | | Conflicts: src/quick/items/qquickloader.cpp tests/auto/quick/qquickanimations/tst_qquickanimations.cpp Change-Id: I0cb9f637d24ccd0ecfb50c455cc210119f744b02
| * QQuickRenderControl: Grab framebuffer with alpha if the window uses itAndy Shaw2018-07-121-1/+2
| | | | | | | | | | Change-Id: Ie11e86be997d749e6f82f0fb81a82bb0b50ab1f1 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | Fix crash with the QQuickRenderControl and deleteLaterDavid Edmundson2018-06-241-1/+0
|/ | | | | | | | | | | | | | | | From 238cc098d785b4fe76fbc8422b340d98ff8c1a1b which removes this same line from the software renderer. >I can't see a good reason for the existence of the sendPostedEvents() >call there. It is not present in the other render loops and according to >git blame it stems from the very early first implementation of the >software renderer where surely copy & paste from other render loop code >was involved back then. Task-number: QTBUG-68997 Change-Id: I40aaeb92f431d474b7b1affb85d0ea5f8b2a46ef Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-9/+9
| | | | | | | | | | | | | 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>
* Fix QQuickRenderControl software grabs on surface not rendered elsewherev5.10.0-beta2David Edmundson2017-10-141-2/+2
| | | | | | | | | | | | The softwareRenderer is created in QQuickWindowPrivate::syncSceneGraph If a window is purely offscreen and only read with grabs() this never gets created as we check the software renderer too early. This can be fixed by reordering some code. Change-Id: I882a8c11ab5d285a54b32ab4f53abfbc8c50f449 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Delay the deletion of QSGTextures until all windows are synchronizedDominik Holland2017-06-161-0/+3
| | | | | | | | | | | | | | | | With the 'basic' and the 'windows' render loop the scene graph context is shared. Because of this we cannot start deleting textures after the first window is synchronized as it may contain textures needed by the another window, which is not yet synchronized. QWindowPrivate::syncSceneGraph() is not calling endSync() anymore as it doesn't know whether it is the last window or not. Instead the renderloop is now responsible for calling endSync() once this is safe to do. Change-Id: Icb50ebfb447c928e38b41df7e26f3bfafdb4a811 Reviewed-by: Robert Griebl <robert.griebl@pelagicore.com> Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
* Run includemocs in qtdeclarativeThiago Macieira2017-04-261-0/+2
| | | | | Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix hidpi support for opengl window grabbingFilipe Azevedo2017-04-091-0/+3
| | | | | | | | | | Now set the QImage devicePixelRatio so the content is correct on all screens. Task-number: QTBUG-53795 Change-Id: If94edf901da1285afe9bb847b8973d568a2b7082 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix wrong grabbing behaviorFilipe Azevedo2016-12-201-0/+5
| | | | | | | | | | | | QQuickWidget::grabFrameBuffer() was not polishing its items nor syncing the scene graph compared to standard QQuickWindow::grabWindow(). This lead to QQuickWidget grabbed content to be outdated (render the previous frame as a new frame). Task-number: QTBUG-57596 Change-Id: I94f5e0aa5b096fb9e21259267c0e50473e8ed5bd Reviewed-by: Robin Burchell <robin.burchell@viroteck.net> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Get rid of most QT_NO_FOO usagesLars Knoll2016-11-291-4/+4
| | | | | | | | Instead use QT_CONFIG(foo). This change actually detected a few mis-spelled macros and invalid usages. Change-Id: I06ac327098dd1a458e6bc379d637b8e2dac52f85 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Make shader effects configurableLars Knoll2016-10-101-1/+3
| | | | | | Change-Id: I4e7fd5e9781dec7ee6ed8807ca1a51c937f6f9f3 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix up QQuickWidget and QQuickRenderControl docsLaszlo Agocs2016-07-151-2/+7
| | | | | Change-Id: I4df82c62afc12dace513ccbf6475d980c041867e Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix rendercontrol grabs with the software backendLaszlo Agocs2016-07-151-5/+24
| | | | | | | | | | | | Calling grabWindow recurses (since that is implemented via QQuickRenderControl::grab...) so it's not an option. Instead, call directly in the software renderer implementation. Fix also the size of the offscreen QQuickWindow when using QQuickWidget in combination with the software backend. Change-Id: I857a2cc0aebbbaa5d52d809aeaec37c15b0787b9 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Merge remote-tracking branch 'origin/dev' into scenegraphngAndy Nichols2016-05-311-1/+1
|\ | | | | | | Change-Id: I35715e07b6f837f21cd8e8898f19d97af92c6b69
| * QQuickWindow: Process a synthetic hover once per frameRobin Burchell2016-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the limitation that hover only changes when the mouse moves, and (in my opinion) is required to make hover functionality even remotely useful. QtQuick scenes are a dynamic medium, items can move (or change) frequently, so only changing this in response to a user action means it will frequently end up out of date. A very simple example of this is a ListView of delegates that each have a background set on hover: when flicking the list, it won't reset the hover to actually match the item under the mouse. This is now not a (very) expensive operation to do, as deliverHoverEvent does nothing if the item tree in question doesn't have hover enabled. [ChangeLog][QtQuick][MouseArea] Hover state is now updated once per frame. This means that MouseArea::containsMouse property will now be correct even if the mouse is not moving, but items move under the cursor. Likewise the mouse position properties and positionChanged signal will act as if the mouse had moved. Task-number: QTBUG-40475 Task-number: QTBUG-42194 Task-number: QTBUG-33982 Task-number: QTBUG-42578 Task-number: QTBUG-52537 Change-Id: Ic2dcbb45339e11c07f5c6a9c95eb7f64957968eb Reviewed-by: Gunnar Sletta <gunnar@sletta.org> Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 15:25:07 +0000