aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickwindow_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Enable importing OpenGL textures for the GL_TEXTURE_EXTERNAL_OES targetLaszlo Agocs2021-01-141-1/+8
| | | | | | | | | Introduce a QSGOpenGLTexture::fromNativeExternalOES() function which internally passes in the flag QRhiTexture::ExternalOES when creating the wrapping QRhiTexture. Change-Id: I919e2539304d3aeaa6bc8e5953d96adc810abb12 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Fix tst_QQuickMouseArea::notPressedAfterStolenGrab againShawn Rutledge2020-11-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem() doesn't need to call item->mouseUngrabEvent() because all grab changes are notified via the connection from signal QPointingDevice::grabChanged to slot QQuickWindowPrivate::onGrabChanged(). But in this case, MouseArea only accepts the event, rather than taking the grab itself. Therefore at the time the grab is "stolen", there was not yet any grabber, because grabbing is done after delivery. But we still need to inform MouseArea that it's not getting the grab it expects to get, so that it can reset its pressed state. But we don't want it to be redundant (other tests are counting events, and we don't want repeated ungrabs to show up in those); so now we have to track whether the item on which we're about to call mouseUngrabEvent() has already gotten it. This illustrates another problem with the tradition of accepting events and being unclear about what it means. Grabbing is one thing, ending delivery is another. Amends a97759a336c597327cb82eebc9f45c793aec32c9 Task-number: QTBUG-55325 Task-number: QTBUG-86729 Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickItem::windowDeactivateEvent(); cancel grabs insteadShawn Rutledge2020-11-191-0/+1
| | | | | | | | | | | | | | | | | | | When a QQuickWindow is deactivated, visiting every item in the entire scene to tell them the news isn't very efficient, especially considering that the only item that overrode this virtual function has been QQMouseArea, throughout the lifetime of Qt 5. If it's important to cancel grabs of MouseAreas, then it's equally important to cancel grabs of MultiPointTouchArea, pointer handlers, etc. It should be OK to delete the virtual function since it was never documented, and marked \internal, so hopefully no users are depending on it. The existing tst_QQuickMouseArea::pressedCanceledOnWindowDeactivate() test continues to pass, which proves that the WindowDeactivate event still has the desired effect on MouseArea. Change-Id: I0109370aba14096fb7777a83cf1b6763ac58013f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QMutable*Event classes to copy and synthesize eventsVolker Hilsheimer2020-11-181-1/+1
| | | | | | | | | | QMutableTouch/SinglePointEvent can be publicly copy constructed from their non-mutable counterparts, make use of that. Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Avoid calling QQuickItemPrivate's methods if QQIP is incompleteFabian Kosmale2020-11-171-0/+2
| | | | | | | | | | | | | | | | In QQuickWindow, we instantiate QQuickPaletteProviderPrivateBase, which in turn instantiates its updateChildrenPalettes method, which then calls QQuickItemPrivate::inheritPalette. However, QQIP is an incomplete type at this point. Including qquickitemprivate_p.h would currently create a cyclic dependency, and breaking that dependency might mean outlining performance sensitive code. Thus we instead (ab)use the fact that updateChildrenPalettes is virtual, do nothing in the specialization for QQuickWindow and instead implement the method in the same way as an override in QQuickWindowPrivate. Task-number: QTBUG-88457 Change-Id: I49b357d7a67f1945a4d3c25e8cabd428d1454aa7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Teach flickable to handle and replay touch as it does mouseShawn Rutledge2020-11-111-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQmlListProperty: Use qsizetype rather than int for sizesUlf Hermann2020-11-091-3/+3
| | | | | | | | | | [ChangeLog][QtQml] The QQmlListProperty callback functions use qsizetype now as type for the size of a list. This is in line with the containers that you might use to back the list. Fixes: QTBUG-88269 Change-Id: Ia38403cb32f241e6c70e1a580dbeff1d6d694331 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Handle ungrab and grab-cancel consistently; inform handlersShawn Rutledge2020-09-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call onGrabChanged on Pointer Handlers during grab transitions: this was missing in a97759a336c597327cb82eebc9f45c793aec32c9. Flickable needs to receive an ungrab by child-event-filtering, in order to set its pressed state back to false (as in the cancelOnHide autotest). This is best done as a result of the QPointingDevice::grabChanged signal, while trying to send the ungrab to the item that was the grabber, rather than as a special case. Thus, QQuickWindowPrivate::onGrabChanged (the handler for the QPointingDevice::grabChanged signal) is now the only place from which we call QQuickItem::mouseUngrabEvent() and touchUngrabEvent(). But the result is that they are called in more cases than before, so some tests need adjustment. touchUngrabEvent() is not sent unless the event is available and we can verify that all points have been released. This is important for MultiPointTouchArea: it will react by ending interaction with all points at once. Another thing that's important to MPTA and multi-touch handlers is that QQuickWindowPrivate::deliverPointerEvent() must not clear grabbers of points that are not yet released, in the case that only some points are. QQuickWindowPrivate::removeGrabber() now calls QPointingDevicePrivate::removeGrabber() with its optional cancel argument, so that it will emit either a cancel or an ungrab transition. That's only relevant for Pointer Handlers, whereas QQuickItem mouseUngrabEvent and touchUngrabEvent don't make a distinction. Task-number: QTBUG-86729 Change-Id: Idf03aef2e2182398e0fc4a606c0ddbb2aaed5681 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-22/+33
| | | | | | | | | | | | | | | | | | | | | | | QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add type safe native texture accessorsLaszlo Agocs2020-08-031-0/+5
| | | | | | | | Following the pattern from QtGui. Task-number: QTBUG-85239 Change-Id: I07b4456028d0f45223ad10e55ce65f423bab6a9b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Begin handling the QEvent refactoringShawn Rutledge2020-07-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This is an intermediate step to get Qt Quick working again after qtbase 4e400369c08db251cd489fec1229398c224d02b4. - QQuickEventPoint::id() is no longer unique across devices, because now eventPoint.event.device tells which specific device the event comes from. (In Qt 5, we could not yet add the device pointer to QInputEvent.) - However, MultiPointTouchArea's docs say that each pointId is unique, and so do the HandlerPoint docs (for similar use cases with PointHandler). So we still need the same hack using a Qt-specific short device ID to unique-ify the QEventPoint::id(). Now we use the device index in QInputDevice::devices() as the short ID. - Otherwise, we trust QInputDevice::systemId() and QEventPoint::id() more than before. - Use QMutable* classes from qevent_p.h to continue using setters that were in QTouchEvent before, etc. But setTouchPoints() is not there, so we have to make new event instances in a couple of cases. - QGuiApplicationPrivate::setMouseEventCapsAndVelocity() and setMouseEventSource() are gone. - Use (compiler-written) event copy constructors when possible. Task-number: QTBUG-72173 Change-Id: I3915dc535ae4c5a81cbf333aba9355f01c420c15 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Replace QTouchEvent::TouchPoint with QEventPointShawn Rutledge2020-07-151-1/+1
| | | | | | | | | | | | It's a cosmetic change at this time, because we have declared using TouchPoint = QEventPoint; Also replace Qt::TouchPointState enum with QEventPoint::State. Task-number: QTBUG-72173 Change-Id: Ife017aa98801c28abc6cccd106f47a95421549de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-4/+4
| | | | | | | | | | | | | | ...and generally deal with changes immediately required after adding QInputDevice and QPointingDevice. Also fixed a few usages of deprecated accessors that weren't taken care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad. Task-number: QTBUG-46412 Task-number: QTBUG-69433 Task-number: QTBUG-72167 Change-Id: I93a2643162878afa216556f10808fd92e0b20071 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make it possible to specify device extensions in a future proof mannerLaszlo Agocs2020-06-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QQuickWindow: Remove (set)ClearBeforeRenderingLaszlo Agocs2020-06-161-2/+0
| | | | | | | | | | | | | | | | | | The doc update reveals that this setting has been ignored with the RHI always, and there is no plans (or ways) to support this. As the beforeRenderPassRecording() signal documents, connecting to that signal is effectively an alternative to disabling clearing the color buffer. (because it allows the application to execute custom GL or other calls after the clear but before the rest of Qt Quick's rendering) Therefore, remove the clearBeforeRendering flag from Qt 6. [ChangeLog][Qt Quick][QQuickWindow] setClearBeforeRendering() and clearBeforeRendering() are removed. Change-Id: I6a0a6f56552331923f2e07390e2f33f58c6c31e0 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove the GL/ANGLE-ish QQuickWindowPrivate::contextCreationFailureMessageLaszlo Agocs2020-06-161-3/+0
| | | | | | | | 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>
* Remove QtQuick.Window pluginUlf Hermann2020-06-151-0/+2
| | | | | | | | | | | | | | | | | We move all the types into QtQuick itself and retain QtQuick.Window only as alias to QtQuick. This requires support for qmldirs that consist of only an import statement. [ChangeLog][QtQuick][Important Behavior Changes] The contents of the QtQuick.Window QML module have been moved into the QtQuick module. QtQuick.Window is merely and alias for QtQuick now. An explicit import of QtQuick will override this alias. Therefore, if you import QtQuick with a different version than QtQuick.Window, you will get the QtQuick.Window types of the version given in the QtQuick import now. Task-number: QTBUG-84639 Change-Id: Ia82afab0ac2faba70cfdaf53dc8dfe4261e1113f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Move resetOpenGLState() to QQuickFboLaszlo Agocs2020-06-121-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make openglContext getter in QQuickWindow privateLaszlo Agocs2020-06-111-0/+2
| | | | | | | | | | | | Fix up the scenegraph and qquickwindow autotests as well. (direct OpenGL specifics are now completely removed from both, i.e. the remaning OpenGL specific tests are now run (and not skipped) with OpenGL-on-RHI) [ChangeLog][Qt Quick][QQuickWindow] openglContext() has been removed from QQuickWindow. Use QSGRendererInterface to query the QOpenGLContext. Change-Id: If5c9802b71ac5f9cffc695827e286eb2a2d03580 Reviewed-by: Andy Nichols <andy.nichols@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>
* Remove openGLContextCreated signalLaszlo Agocs2020-06-101-1/+0
| | | | | | | | | | | | | | | | No reason to have this in the API in 6.0, and it's already not emitted at all in dev (because the direct OpenGL code path is now gone from the render loops) Some simple GL string printing has been removed from qml/qmlscene. This opt-in feature has not been useful in practice anyway since QSG_INFO=1 prints the same things. [ChangeLog][Qt Quick][QQuickWindow] The openGLContextCreated signal has been removed from QQuickWindow. Change-Id: Ifb647bbd1e828ebad2b775e8ce5c38723a0cda13 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Add perspective 3D plane render modeLaszlo Agocs2020-06-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | One can now do rc->createRenderer(QSGRenderContext::RenderMode3D) in Quick3D. By default nothing changes, both QQuickWindow and QSGRhiLayer default to either RenderMode2D or RenderMode2DNoDepthBuffer, depending on QSG_NO_DEPTH_BUFFER. (the environment variable handling is moved out of qsgbatchrenderer.cpp however, leaving it up to whoever is creating the renderer to passing the appropriate flag) The RenderMode3D mode is a modified version of the QSG_NO_DEPTH_BUFFER case: only alpha batches are used, which are then rendered back to front. The difference is that this is done with depth test on (no write), so the 2D content gets depth tested against whatever is already in the depth buffer. Then, there's an additional depth "post pass" to fill the depth buffer with the 2D content. This must be separate from the color-write enabled stage because otherwise unavoidable Z fighting would occur. By filling the depth buffer, other 3D or 2D content, that is rendered afterwards, can depth test correctly against the 2D elements rendered here. customRenderMode and related functions are renamed to visualization (because that's what it is about), in order to prevent confusing name clashes. Change-Id: I0d43b273e0a8020af05a652a236c0ad5fb150685 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove customRenderStage from QQuickWindowPrivateLaszlo Agocs2020-06-081-9/+0
| | | | | | | | | | | | This is not maintained and probably not compatible with QRhi-based rendering anyways. Remove it for now. Task-number: QTBUG-84718 Task-number: QTBUG-84623 Change-Id: I423b45e247c751c94f1407cfb53f056d6ea7a10c Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Quick: Clean up some includesUlf Hermann2020-06-041-5/+5
| | | | | | | Uniformly use <...> and sort them by modules. Change-Id: I11cd160783dfb141d8824d635bdc56a63aaee50f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Expose the QRhiSwapchain via QSGRendererInterfaceLaszlo Agocs2020-06-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...similarly to how we already do it for the QRhi itself. Just follow the same pattern. This allows Qt Quick 3D to stop peeking directly into QQuickWindowPrivate and accessing member variables in there. Code like the following QQuickWindowPrivate *wd = QQuickWindowPrivate::get(window); QRhiCommandBuffer *cb = wd->swapchain->currentFrameCommandBuffer(); QRhiRenderPassDescriptor *rp = wd->rpDescForSwapchain; can now be written ca. like this, without pulling in quick-private: QRhiSwapChain *swapchain = window->rendererInterface->getResource(window, RhiSwapchain) QRhiCommandBuffer *cb = swapchain->currentFrameCommandBuffer(); QRhiRenderPassDescriptor *rp = swapchain->renderPassDescriptor(); This provides a more stable interface between the scenegraph and Quick 3D. In addition, this is also handy for manual tests, external test applications, etc. in case they do QRhi-based rendering in a QQuickWindow. Now these are also fine with just gui-private, no need to access QQuickWindowPrivate anymore. Change-Id: I921fb1c33c2fc77081272b1f180fdc2c87ed3ab5 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove OpenGL FBO references in QQuickWindow and the renderer APILaszlo Agocs2020-06-021-7/+0
| | | | | | | | | | | | | | setRenderTarget(GLuint), setRenderTarget(QQuickFramebufferObject*), renderScene(uint fboId), QSGBindable, etc. are now removed. This leads to a simpler and cleaner interface in QSGAbstractRenderer and QSGRenderer because the somewhat weird renderScene() overloading (where one version is virtual, while the other isn't) is now avoided, with just a single renderScene() virtual now. Task-number: QTBUG-84040 Change-Id: I0ce5a159a557688bdfcb7cacf8a9d12d6fd970d1 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* RHI: Fix crash in QQuickWindow when updating render targetEskil Abrahamsen Blomfeldt2020-05-141-1/+1
| | | | | | | | | | | | | | | | | The crash is reproducible e.g. when a resize event comes after a render target has been created, and it has to be recreated. It would then delete the render pass descriptor but it would still be in the pipeline cache in the renderer. We need to tell the renderer it is invalidated before deleting it. Discovered as part of making QQuickWidget work on RHI. The crash was reproducible by creating a new tab widget in the qquickwidget example. Task-number: QTBUG-78638 Change-Id: Ia840cc423a811aee18c568d43624b6bf852246f7 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Allow redirecting QRhi-based rendering via QQuickRenderControlLaszlo Agocs2020-04-111-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-03-091-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/compiler/qqmlirbuilder_p.h src/qml/qml/qqmlpropertycachecreator_p.h src/qmltyperegistrar/qmltypesclassdescription.cpp src/qmltyperegistrar/qmltypesclassdescription.h src/qmltyperegistrar/qmltypescreator.cpp src/quick/items/qquicktext_p.h src/quick/util/qquickvaluetypes_p.h Change-Id: Ic209741592e7b85820bf3845722023a190ebc1c5
| * Export QQuickRootItem to QMLUlf Hermann2020-02-251-1/+1
| | | | | | | | | | | | | | It was exported in 5.14, so we should probably still do so. Change-Id: Id44783c72fff50aee63d7c5a72f12ff9ca895a6b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Quick: Don't qualify OpenGL includes (part two)Johan Klokkhammer Helsing2020-02-181-3/+0
|/ | | | | | | | | | | | 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>
* Use the extended QQmlListProperty interface in a few placesUlf Hermann2020-02-071-0/+2
| | | | | | | Task-number: QTBUG-79263 Change-Id: If518f644b5b9eddbacfb1cb16fbb557127ffcfb2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add PointerHandler.cursorShape propertyShawn Rutledge2020-01-311-1/+2
| | | | | | | | | | | | | | | | | | Also, QQuickItemPrivate::setHasCursorInChild() was unable to check the QQuickItemPrivate::hasCursor variable, because the function argument hasCursor was shadowing that, even though the comment "nope! sorry, I have a cursor myself" hints that the intention was to check that. So this change exposed a problem there, and we have to fix that too, in order to keep the tst_qquickwindow::cursor() test passing. [ChangeLog][Event Handlers] Pointer Handlers now have a cursorShape property to set the cursor when the handler is active and the mouse is hovering, and restore to the previous cursor when the mouse leaves. Fixes: QTBUG-68073 Change-Id: Ib5c66bd59c4691c4210ee5465e1c95e7bdcf5ae1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make the initialization failure dialog sensible with QRhiLaszlo Agocs2019-11-281-2/+4
| | | | | | | | | | | | | | | 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 threaded render loopLaszlo Agocs2019-11-281-1/+2
| | | | | | Task-number: QTBUG-80365 Change-Id: I929fb76eb8d023ab048f6d1c91be078de3cfe750 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Avoid initializing QFlags with 0 or nullptrAllan Sandfeld Jensen2019-11-221-2/+2
| | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-101-1/+1
|\ | | | | | | Change-Id: I2835748c27616103f275849141fbe5a93e3dfd8c
| * QQuickWindow: Higher z-order items now steal drop targetStephen D'Angelo2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, an active drop target would remain the drop target until the drag left it's area, or entered a child item that accepted a DragEnterEvent, even if the drag entered a drop target with a globally higher z-order from a different subtree. When moving to an item with a higher z-order, the DragEnterEvent is now sent to the new drop target before DragLeaveEvent is sent to the old drop target. There can now only be one drop target. If an item is the current drop target and a higher z-order child accepts the DragEnterEvent, the parent is no longer a drop target. Fixes: QTBUG-30305 Change-Id: I7b985d6317be70867e7727222a4cd44ace7559e6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-041-1/+1
|\| | | | | | | | | | | | | | | Conflicts: src/imports/qtquick2/plugins.qmltypes src/quick/items/qquickitemsmodule.cpp Change-Id: I841c65c9c131354788b4f3fcfe3d7ed27be316d5
| * 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>
* | Restore QQuickWindowPrivate::dragOverThreshold(d, axis, TouchPoint)Shawn Rutledge2019-09-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 2f85907193ad934d911fe97f7000ecb0662de8cb we added the first version of dragOverThreshold() for checking touchpoints. Then we turned it into a template function in 558bb0e3bbbd3eaca52b02946374f2106c3a3872 along with fixing a bug. This version is still in use in Qt Quick Controls 2: dragOverThreshold(qreal, Qt::Axis, const QTouchEvent::TouchPoint *, int) So now we restore it, keeping the bug fix, but not as a template function. Since ab5df626bef9365089ce716ce476bccae1d0a04b, Pointer Handlers do not need it for checking QQuickEventTouchPoints anymore. Change-Id: I97b84f533f52fa67ccd15ba6eb3ee64a4fe1b668 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Add dragThreshold property to Event HandlersShawn Rutledge2019-09-191-20/+0
|/ | | | | | | | | | | | | | | | | We need drag threshold to be adjustable on each handler instance instead of relying only on the system default drag threshold. For example in some use cases DragHandler needs to work with a threshold of 0 or 1 to start dragging as soon as the point is pressed or as soon as the point is moved, with no "jump", to enable fine adjustment of a value on some control such as a Slider. This involves moving the dragOverThreshold() functions that handlers are using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that they can use the adjustable threshold value. Task-number: QTBUG-68075 Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add the graphics api independent scenegraph portLaszlo Agocs2019-07-041-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add a feature for Drag&Drop support in Qt QuickUlf Hermann2019-05-231-2/+2
| | | | | | | | | | | Even if we have drag&drop in QtGui we don't necessarily want it in QtQuick. Also, since the QQuickDropArea needs QRegularExpression, quick-draganddrop needs to depend on regularexpression. Change-Id: I623e910178160ad3e3af3c01c96c30e88dc1b7ba Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do not synthesize a double click event if the event point moved too farJan Arve Sæther2019-05-151-1/+2
| | | | | | | | We need to respect QPlatformTheme::TouchDoubleTapDistance Fixes: QTBUG-75770 Change-Id: I2adc7097bb29cb93beb2609a8a806a666856a0c8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQWindow: cancel touch->mouse synthesis when touch is ungrabbedShawn Rutledge2018-10-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, each time a new touchpoint is pressed, we would purposely forget which touchpoint was acting as the mouse, as part of "starting over" with event delivery. Conceptually "starting over" ought to mean as freshly as possible; but in practice, if a user was using one finger to interact with some mouse-only Item, and then presses a second finger (whether intentionally or not), (s)he doesn't want the first interaction to immediately end. The multi-finger DragHandler must be able to take over the grab from the Item which already had the grab; but it uses a passive grab in the meantime to track the movement, and normally takes over the exclusive grab only when its preconditions are met: the point has to move past the drag threshold. So we can wait until then to reset the touchMouseId. The concrete use cases are: double-tapping a map is supposed to zoom in, even if there is a MouseArea on top. And, while dragging a Slider inside a Flickable, you should be able to start dragging the Flickable with a second finger. In the first case the issue was that the MouseArea could grab while handling the synth-event, thus setting touchMouseId; then touchMouseId was immediately reset again while handling the second touchpoint, so the second touchpoint would also be offered as a synth-mouse event to various items. But while fixing that, we have to avoid this issue in the Slider-in-Flickable case: when the first touch press is delivered, Flickable takes the exclusive grab temporarily; after moving the touchpoint, the Slider's DragHandler steals the exclusive grab. Then we try to deliver the second touchpoint press: at this time, we don't want touchMouseId to be set, because we want to be able to deliver synth-mouse events for the second point so that Flickable can grab that one. So it must be that when DragHandler steals the grab, we can reset touchMouseId, because the only reason it was set was that Flickable had the grab. This result is achieved by having QQuickItem::touchUngrabEvent() call a new QQuickWindowPrivate::cancelTouchMouseSynthesis() function. It was already a good idea to have such a function since we always reset touchMouseId and touchMouseDevice at the same time. Also modify the docs to remind users that when subclassing QQuickItem and overriding mouseUngrabEvent() or touchUngrabEvent() they should call the base class implementation, to avoid bypassing this new functionality. Fixes: QTBUG-70998 Change-Id: I02894971e9047d4fa7ac9d062d6714c9183a8058 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-191-0/+1
| | | | | | | | | | That is, minimumPointCount can now be set to a value > 1 to require multiple fingers to do the dragging, or to track the displacement of multiple fingers to adjust some value (such as the tilt of a map). Task-number: QTBUG-68106 Change-Id: Ib35823e36deb81c8b277d3070fcc758c7c019564 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Replace MultiPtHndlr.pointDistanceThreshold with PointerHandler.marginShawn Rutledge2018-06-291-1/+1
| | | | | | | | | | | | | | | | It's not just useful for PinchHandler: TapHandler has a good use for it too. But unfortunately if the handler's parent Item has a custom mask, we don't have a way to augment the mask with a margin; so if margin is set, we assume the bounds are rectangular. QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint() rather than bounds-checking the point directly: this adds flexibility, potentially allowing an override in subclasses, if we need it later. Task-number: QTBUG-68077 Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Deliver QNativeGestureEvent via deliverSinglePointEventUntilAcceptedShawn Rutledge2018-06-211-3/+0
| | | | | | | | This just simplifies the code a little, and also enables event filtering during delivery to Items. Change-Id: I407dc9a19207f977b574f2a92f5da892e8752987 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-22 02:06:53 +0000