aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/scenegraph/qsgrenderloop.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add env.vars. to toggle pipeline cache load/saveLaszlo Agocs2021-01-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Do grabs out of orderLaszlo Agocs2020-10-191-43/+52
| | | | | | | | | | | | | ...while extending the autotest to cover more complicated cases, such as grabbing again after show-hide and doing show-grab-hide-grab-show-grab. In fact some of these cases have not been working in Qt 5. Now the basic render loop is fixed up to support the all the combinations threaded does. Task-number: QTBUG-87399 Change-Id: Id01995bc3a2660b16cfb2f8bedc84becea0be1bb Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Follow rhi per-frame to per-pass flag changeLaszlo Agocs2020-10-051-3/+1
| | | | | Change-Id: I728cecd85807eb835703a0bb8bb4acdb1f2068ae Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Map swap interval 0 to NoVSync with all the APIsLaszlo Agocs2020-09-231-1/+7
| | | | | | | | | What exactly this will cause is another question. But at least now the traditional OpenGL way of setting the QSurfaceFormat's swapInterval 0 will have an effect with the other APIs as well. Change-Id: I6d50952502a70e84828ed87347e2a948299f6f42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Output the thread and window in the render loop timing printsLaszlo Agocs2020-09-091-7/+8
| | | | | | | | Also fixes a plain bug in the basic render loop: using static to measure elapsed time is broken in a multi-window setup. Change-Id: Ie81fd9f4ec274f8ef095a8be7f280173f143de04 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Render loops: ignore update reqs during the main polish stepLaszlo Agocs2020-09-071-0/+10
| | | | | | | | | | | | The classic example is Shape, which needs to dirty the QQuickItem in updatePolish() in order to get it picked up in the synchronize step. That part is fine, but we do not want maybeUpdate() to issue a requestUpdate() then since we are effectively in progress of doing an update, so having another full round of polish/sync/render is a waste. Task-number: QTBUG-86089 Change-Id: Ie41563b34da17e7134631791ed024b31e87e21e3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix qt.scenegraph.time.renderloop time logjiu2020-08-311-1/+1
| | | | | | Fixes: QTBUG-86209 Change-Id: Iea09d22f09df3b50ebdf55d1c72affb5603bdcda Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Do not create depth/stencil buffer when the env var says soLaszlo Agocs2020-08-161-5/+8
| | | | | | | | | | | | | | | | | | | | | | | Both for the swapchain and more importantly, layers. The latter was never implemented, not in Qt 5 with OpenGL either, and it becomes a problem for resource-limited use cases because QSG_NO_DEPTH_BUFFER still creates depth/stencil attachments for layers even though the 2D rendering has no use for those then. Clarify the QQuickGraphicsConfiguration docs as well. The story is fairly convoluted, because the useDepthFor2D flag one can set from C++ is not 100% the same as the env.var. (and it really should not be) The flag is about relying on depth testing in 2D (and so enabling the potentially more efficient opaque batches), but it does not prevent adding a View3D or other stuff that requires a depth buffer. The env.var on the other hand does both: it (depending on the platform) disables depth (and often stencil) buffers, thus using fewer resources, and also triggers the depth-less 2D rendering path (alpha batches only). But that is not always compatible with 3D then (like an offscren View3D will work, other modes may not) Change-Id: I5ac1ce154fe78a3ec8bd1a698c1c0b944ce8077e Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix crash when QSGTexture is deleted in rc->endSync()VaL Doroshchuk2020-08-071-1/+9
| | | | | | | | | | | | | | | | | | | | | 1. When the quick pixmap is cached, it might be deleted by a timer. 2. When its QQuickPixmapData is being deleted, its QQuickTextureFactory is also deleted. Which informs the QSGRenderContext to postpone deleting of a texture that belongs to this texture factory. 3. When an update is called on the _hidden_ window, QSGGuiThreadRenderLoop::renderWindow calls rc->endSync(), which deletes postponed the texture from 2. After that the texture must not be used. But some QSGNode can still keep pointer to the deleted QSGTexture. and when updatePaintNode is called, it might produce a crash. So, suggesting a fix to inform the render loop that there is a window with pending updates, and no need to delete textures. Change-Id: I1487595dbb686e682ac3b91b9c3d21f401095daa Pick-to: 5.15 5.12 Fixes: QTBUG-65170 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix multiple windows with Vulkan on basic render loopLaszlo Agocs2020-07-281-0/+5
| | | | | | | | | | | | | No problems with threaded, but when using QSG_RENDER_LOOP=basic with Vulkan we missed setting the Vulkan instance for the second, third, etc. window. The problem can be seen with the quick/window example, running it with QSG_RHI_BACKEND=vulkan QSG_RENDER_LOOP=basic makes it fail. With the patch it will function as expected. Change-Id: I98e7cb5ff960200dadb2fcbc30f771f9a7d9a9ae Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix before/after frame signal emissionsLaszlo Agocs2020-07-011-2/+3
| | | | | | | | | Make the before signal closer to the actual QRhi::beginFrame() call. This fixes emitting a beforeFrameBegin unnecessarily when unexposing and then exposing a window again. Change-Id: Icc562a57798986c8d04c6800eabc41981c5da85b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Add ; to Q_UNUSED and UNUSED_PARAMLars Schmertmann2020-06-261-1/+1
| | | | | | | | | This is required to remove the ; from the macro with Qt 6. Task-number: QTBUG-82978 Change-Id: Iead53d18fd790fb2d870d80ef2db79666f0d2392 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Make it possible to specify device extensions in a future proof mannerLaszlo Agocs2020-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-24/+2
| | | | | | | | | | 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>
* Remove the GL/ANGLE-ish QQuickWindowPrivate::contextCreationFailureMessageLaszlo Agocs2020-06-161-9/+3
| | | | | | | | Not called in practice anymore, remove the corresponding condition in the basic render loop as well. Change-Id: I22d6091c900ce36665b9e7f6dc91cc9276528ff6 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Make render loops OpenGL cleanLaszlo Agocs2020-06-081-103/+22
| | | | | | | 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-6/+0
| | | | | | | | | 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>
* Remove winrtOliver Wolff2020-06-041-2/+2
| | | | | | | | | Task-number: QTBUG-84434 Change-Id: If8f57f00726868a3540c877d07fca761618e4f08 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix handling of destroy-show and re-enable the zoom test for qmlpreviewLaszlo Agocs2020-06-031-4/+6
| | | | | | Fixes: QTBUG-84059 Change-Id: Id70c043f96e9525a5a6053efbf99c5ea3408da65 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Follow QRhi create-destroy API updateLaszlo Agocs2020-06-021-1/+1
| | | | | Change-Id: I0bc2cbce373febcb9073f15067eebbc1723462ba Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* rhi: Add support for grabbing non-exposed windowsLaszlo Agocs2020-05-181-1/+1
| | | | | | | | | tst_qquickwindow::grab is now expected to pass in all combinations (both direct GL and RHI with any backend). Task-number: QTBUG-78608 Change-Id: I8c1f2ff3d50144c7dd4498160818d0860b67db15 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Have the basic render loop notify when the renderpass desc. disappearsLaszlo Agocs2020-05-111-0/+9
| | | | | | | | | | | | | | | | Unlike the threaded one, this runs into the well-known issue of referencing the QRhiRenderPassDescriptor from data structures that are tied to the rendercontext. In the 'basic' loop there is one rendercontext that is reused for all windows. With threaded there would be one rendercontext per window, because there each window gets its own render thread, and so the problem cannot arise. Fix up the basic loop accordingly. Change-Id: Iea6713c6167ead7df96ac5f01d7b92d2ec57ce71 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Remove the 'windows' render loopLaszlo Agocs2020-05-041-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For compatibility, QSG_RENDER_LOOP=windows shows a warning and uses basic. For OpenGL proper, threaded is the default on Windows since Qt 5.5, so this will not affect there in any way. By default the windows loop was only used with ANGLE, or a non-standard opengl32 implementation like the Mesa llvmpipe shipped with the pre-built Qt packages. (and only on Windows, as the name suggests, even though the implementation of this loop is not tied to Windows in any way) For these we default to basic now. This will make no difference in practice: The windows render loop's value is that it takes the custom animation driver (advanced per frame, assuming that vsync-based throttling is active) approach from the threaded loop, while behaving like basic otherwise, thus providing smoother animations compared to basic, in theory. But due to its relatively little use (not the default since 5.5), ANGLE being removed in the near future, and not making much sense for the software rasterizer cases (those will have bigger problems than smoothly advancing animations, often providing no vsync, so they are better off with basic anyways), it makes no sense to invest into adding QRhi support for this loop too. Task-number: QTBUG-78578 Task-number: QTBUG-82997 Change-Id: I8ccd2e5e375799df5bb5018df247aa5b8197032a Reviewed-by: Andy Nichols <andy.nichols@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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 includesUlf Hermann2020-01-271-1/+1
| | | | | | | | | | | | | The headers are moving from QtGui to QtOpenGL. By avoiding the qualification we can keep them compiling either way. Also, add opengl-private to make the types available. Also removed the QGraphicsRotation hack to get access to the projected rotation function of QMatrix4x4. The function is public now. Task-number: QTBUG-74409 Change-Id: I216e8ca09f8e247f96627b081308e3a57c55c29c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Add trace points for Qt Quick Scene GraphMilian Wolff2019-12-131-0/+13
| | | | | | | | | | | | This adds Q_TRACE tracepoints for all places that are covered by the QML profiler's QSG integration. The big advantage over the existing framework is that these trace points can be visualized next to other system tracepoints to correlate the data better with load and resource consumption induced by other processes on the system. Change-Id: I0c5b70a0870f0b89e4533c351c099e13fd18a55f Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Make the initialization failure dialog sensible with QRhiLaszlo Agocs2019-11-281-8/+11
| | | | | | | | | | | | | | | So on Windows one now gets a message box with a reasonable message, instead of the OpenGL nonsense. Then the application closes when pressing Abort etc. On other platforms there is a qFatal, printing the same message. Involves simplifying the OpenGL version a bit since passing isES type of flags through multiple layers is not justified here. Task-number: QTBUG-80365 Change-Id: Ie3ea1e9395a283f7e95eda78c1d3894797ff0acf Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Prevent infinite rhi init failure in basic render loopLaszlo Agocs2019-11-281-7/+27
| | | | | | | Task-number: QTBUG-80365 Change-Id: Iaa2f97b02c4665f0485226d9aa420993330d78f8 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io> Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* Avoid initializing QFlags with 0 or nullptrAllan Sandfeld Jensen2019-11-221-1/+1
| | | | | | | | | It is being deprecated. Change-Id: I844bd92af85bc53a8fc0371408d05277bd49f511 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Handle context loss in the basic render loopDavid Edmundson2019-10-081-0/+18
| | | | | | | | | | | In the event of a graphics context loss, we need to reset the scenegraph and the GL context. As all windows share a graphics context a loss detected in one window needs to reset the scenegraph on all windows. Change-Id: I3ff1a93d5a08fa21366a6a56e94bd2185aebb2d5 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QQuickWindow: Don't leak the animation controllerUlf Hermann2019-10-021-1/+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>
* Remove depth-stencil buffer sizing on the rhi pathLaszlo Agocs2019-09-301-6/+8
| | | | | | | | | ...as this will be done automatically by QRhiSwapChain after the corresponding QtGui changes. Task-number: QTBUG-78641 Change-Id: I8edeb728f3aba07bfa6bc6331966fba4bdee71f4 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Handle rhi device loss in the basic render loopLaszlo Agocs2019-09-231-5/+40
| | | | | Change-Id: I02cee05ce7eee2ad1c458d1a934c210c12d1dea2 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Request correct alpha composition on the rhi code pathLaszlo Agocs2019-09-111-1/+10
| | | | | | Task-number: QTBUG-78089 Change-Id: I22f8bb5ec0af33397df14e064a0306bd4c5a5ef5 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Make vulkanunderqml work and update docsLaszlo Agocs2019-09-081-1/+3
| | | | | | | | | | | | | | | What we are doing for now is setting ExternalContentsInPass always. This way vulkanunderqml works as expected. For applications that do not integrate external rendering this means that there is now an additional secondary command buffer per render pass, but we can live with this for now. Later (Qt 6) there should be a way to declare this (that the application will want to issue native rendering stuff) up front in QQuickWindow or somewhere. Change-Id: I736741f9b0eee2f8295b046bacdce862e6a546f5 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix not printing logs with QSG_INFO when forcing rhi backend from C++Laszlo Agocs2019-08-291-3/+1
| | | | | | | | | | | | | | | QQuickWindow::setScenegraphBackend() may be called before QQuickWindow gets a chance to create a render loop. If QSG_INFO (the env.var.) is used instead of the logging category (qt.scenegraph.general), some logs are not printed because the code that enables the logging category is not yet run. To prevent confusion, make sure the logging category gets enabled before the first potential qCDebug. In the worst case we check twice but that's fine. Change-Id: Ibfc0af05050adc9766c30a2d15c778b2a51823fe Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Enable threaded render loop for d3d11Laszlo Agocs2019-08-141-10/+13
| | | | | Change-Id: I5772b38c59b8fe3f9a30f56d3a559f6161443562 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Minor cleanup and logic fix in basic renderloopLaszlo Agocs2019-08-141-7/+10
| | | | | | | | The (gl) condition is clearly an oversight, the branch should be taken if either gl or rhi are valid. Change-Id: Ieb0a9aeec996f8940716f9fdafe90525b60fc248 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Change rhi-related debug prints to categorized loggingLaszlo Agocs2019-08-021-3/+3
| | | | | Change-Id: I4e8d3111a2f3b77e984756cc9eef49d42f0b647c Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Re-enable threaded render loop with Vulkan on LinuxLaszlo Agocs2019-07-301-8/+0
| | | | | Change-Id: I05440c54b99ddb6aac9a47e8b33a00be41c13055 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Enable request setting the (gl) context current on rhi pathLaszlo Agocs2019-07-041-9/+19
| | | | | | | This was disabled due to the unmerged qtbase api change. Change-Id: I38beb8f2aa11dc233765bcfe06e91940b64b5758 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add the graphics api independent scenegraph portLaszlo Agocs2019-07-041-61/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.11' into 5.12Qt Forward Merge Bot2018-09-111-5/+7
|\ | | | | | | Change-Id: Ieaf0811cf045af1e6df4db4ab67d7c38ba0d1fbf
| * Delete textures even if one of the windows is invisibleVaL Doroshchuk2018-08-271-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | If there is an invisible window that will not be rendered but is constantly requested to render, updatePending is always set. This prevented purging of already unneeded textures, and meant endSync() was never called and m_texturesToDelete was never cleared. Added a fix to clear the updatePending flag regardless of visibility. Task-number: QTBUG-66116 Change-Id: Ib8bf453a3dee18d3d43342580c619664b701acae Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
* Avoid marking hidden windows as updatePending in Gui render loopDavid Edmundson2018-04-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Since eeb320bbd8763f3e72f79369cc3908e999a0da3c the GL context only deletes textures when all windows with pending updates have finished rendering. renderWindow will not process any window that is not visible. This leaves a logic bug that we can have the updatePending flag set but never cleared. If we have two windows, this leaves the other window still updating normally, but lastDirtyWindow will always be false and we never call endSync. This results in an effective memory leak of all textures. This patch resets the flag on hide() a move that can be considered safe given the show() method will reset this flag anyway. Change-Id: Iab0171716e27e31077a66b5e36a00bf28a2e7a8c Reviewed-by: Kai Uwe Broulik <kde@privat.broulik.de> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Dominik Holland <dominik.holland@pelagicore.com> Reviewed-by: Aleix Pol Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-7/+7
| | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 00:19:12 +0000