aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick
Commit message (Collapse)AuthorAgeFilesLines
* Software render: Fix warnings floodFriedemann Kleint2018-05-081-0/+1
| | | | | | | | | | | Add missing QPainter::end(), fixing: QBackingStore::endPaint() called with active painter on backingstore paint device Task-number: QTBUG-66452 Change-Id: Ia00e61953528b15015b3e41ba1868e670818cf14 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit 047f161b1a706e81034ccd8d4700a3126c16dfe4)
* QQuickItem: Guard against null deref in transformationsRobin Burchell2018-05-021-0/+6
| | | | | | | | Change-Id: Ieb14322c104d816842e04e521b556bfc11855f1c Task-number: QTBUG-67024 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> Reviewed-by: Michael Brasser <michael.brasser@live.com> (cherry picked from commit f9686bc68696ad1e99a0587f15d05300d003d990)
* QQuickContext2DFBOTexture: use normalized sub rect when using FBO with POT ↵Richard Moe Gustavsen2018-04-231-2/+17
| | | | | | | | | | | | | | | | | texture When creating a Canvas item with renderStrategy set to Canvas.FramebufferObject we might end up creating an FBO with a POT texture (e.g on iOS) that doesn't match the size of the canvas. The result will be that the image turn out scaled. QSGTexture::normalizedTextureSubRect() is a function that needs to be overridden to be used. So this patch will create a subclass of QSGPlainTexture that overrides it, and returns the normalized subrect inside the FBO that that matches the size of the canvas. Task-number: QTBUG-59192 Change-Id: I0f0e57e117656df21a94b7015bd160c44485046d Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix bug preventing ungrabMouse() on TouchCancelDaniel d'Andrada2018-04-091-4/+5
| | | | | | | | | | | | | | | | | | | | The order matters. There won't be a mouseGrabberItem() after the cancelExclusiveGrabImpl() call. So ungrab the mouse before calling it, not after. This cherry-pick includes some other changes to tst_qquickwindow.cpp (parts of 9d8fe2ac121162c15be6728495be2235b728325a) that enable the cherry-picked test function touchEvent_cancelClearsMouseGrab() to be the same as it is in 5.10 branch. Task-number: QTBUG-63680 Task-number: QTBUG-67445 Change-Id: I1ba6401c5d8eb3417907eb1e6ca20816b501f3ac Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry-picked from 0821180dc833376a738742e33f728983b9ca6f84) Reviewed-by: Tasuku Suzuki <tasuku.suzuki@qt.io>
* Fix crash with the software renderer and windows with QObject parentSimon Hausmann2018-02-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a QQuickWindow is a child of another QObject (such as a Loader) and is scheduled for deletion using a deferred delete event, then a deletion via the parent ends up calling the window's destructor, which will finally end up in ~QObject(), which takes care of removing the posted deferred deletion event from the event queue. In the case of QQuickWindow, the destructor - called before ~QObject - calls windowDestroyed(this) on the SG render loop. The implementation in the software renderer calls QCoreApplication::sendPostedEvents() with QEvent::DeferedDelete, which ends up deleting the same window a second time and resulting in a crash. 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. The same fix is applied to the single-threaded VG and D3D12 render loops, as they are most likely copy & paste from the software render loop implementation. ASAN trace for tst_qquickwindow::unloadSubWindow() on 5.11 branch that shows invalid access to the QObjectPrivate/QQuickWindowPrivate, which follows the QObject in terms of life-cycle: ==4736==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000011778 at pc 0x7fdd211cfbb3 bp 0x7fffecb47ea0 sp 0x7fffecb47e90 READ of size 8 at 0x617000011778 thread T0 #0 0x7fdd211cfbb2 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1308 #1 0x7fdd21470974 in QQuickWindowQmlImpl::~QQuickWindowQmlImpl() items/qquickwindowmodule_p.h:63 #2 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103 #3 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103 #4 0x7fdd1e24da24 in qDeleteInEventHandler(QObject*) kernel/qobject.cpp:4601 #5 0x7fdd1e253d2f in QObject::event(QEvent*) kernel/qobject.cpp:1240 #6 0x7fdd1fbd1d41 in QWindow::event(QEvent*) kernel/qwindow.cpp:2356 #7 0x7fdd211f778e in QQuickWindow::event(QEvent*) items/qquickwindow.cpp:1628 #8 0x7fdd1e1a4e3c in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) kernel/qcoreapplication.cpp:1216 #9 0x7fdd1e1a508b in doNotify kernel/qcoreapplication.cpp:1157 #10 0x7fdd1e1a555a in QCoreApplication::notify(QObject*, QEvent*) kernel/qcoreapplication.cpp:1143 #11 0x7fdd1fb87665 in QGuiApplication::notify(QObject*, QEvent*) kernel/qguiapplication.cpp:1723 #12 0x7fdd1e1a52fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) kernel/qcoreapplication.cpp:1067 #13 0x7fdd1e1b6ed2 in QCoreApplication::sendEvent(QObject*, QEvent*) ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234 #14 0x7fdd1e1b6ed2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) kernel/qcoreapplication.cpp:1764 #15 0x7fdd1e1b8cda in QCoreApplication::sendPostedEvents(QObject*, int) kernel/qcoreapplication.cpp:1618 #16 0x7fdd210cb034 in QSGSoftwareRenderLoop::windowDestroyed(QQuickWindow*) scenegraph/adaptations/software/qsgsoftwarerenderloop.cpp:100 #17 0x7fdd211cfb8c in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1305 [...] 0x617000011778 is located 632 bytes inside of 704-byte region [0x617000011500,0x6170000117c0) freed by thread T0 here: #0 0x7fdd21a8a9d8 in operator delete(void*, unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe19d8) #1 0x7fdd2146fa3c in QQuickWindowQmlImplPrivate::~QQuickWindowQmlImplPrivate() items/qquickwindowmodule.cpp:57 #2 0x7fdd1e26b252 in QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*) [...] #3 0x7fdd1e26b252 in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer() [...] #4 0x7fdd1e26b252 in QObject::~QObject() kernel/qobject.cpp:882 #5 0x7fdd1fbcf51c in QWindow::~QWindow() kernel/qwindow.cpp:211 #6 0x7fdd211d0466 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1297 #7 0x7fdd211d0644 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1335 #8 0x7fdd1e2666b4 in QObjectPrivate::deleteChildren() kernel/qobject.cpp:1995 #9 0x7fdd1e26b329 in QObject::~QObject() kernel/qobject.cpp:1023 [...] Change-Id: Iffa90d365d02b074e2a78c5be2895c9f86a4b80e Task-number: QTBUG-66381 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit 238cc098d785b4fe76fbc8422b340d98ff8c1a1b)
* QQuickItemView::currentItemChanged called upon currentItem destructionAleix Pol2018-02-131-0/+7
| | | | | | | | | There were some cases where the signal wasn't emitted and we ended up with events being delivered to objects that didn't exist anymore. Task-number: QTBUG-65881 Change-Id: I847669a978e82a0332907b029a8295bb993d2850 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Fix performance regressionJesus Fernandez2018-02-072-2/+9
| | | | | | | | | | | Reverts 2c2e7f27426cb4381f2dcaa36affe55719619753. WebGL does not support a shared index and vertex buffer. Due to a performance regression, this patch is reverted. Task-number: QTBUG-66191 Change-Id: I296d2a6c1c7b5fa66532bd7e106f5360d9d2403a Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Use the GL context shared in the render contextErik Verbruggen2018-02-061-15/+20
| | | | | | | | | .. instead of calling QOpenGLContext::currentContext(), which in turn accesses the thread-local storage. Change-Id: I773686deb2a745e066b0878a6ccb087afb81774d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tuukka Turunen <tuukka.turunen@qt.io>
* Fix transition when removing the last item from ListView/GridViewKari Hautamäki2018-02-021-1/+3
| | | | | | | | | Use the previous item view boundaries (before a remove was applied) when defining transition properties. Task-number: QTBUG-64311 Change-Id: I66870a7267ac26ea430c364383f32fd5c47d4a5d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* If Loader loads Window, set its transient parent to the Loader's windowShawn Rutledge2018-02-023-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the Item { Loader { sourceComponent: Window { } } } case consistent with the Item { Window { } } case: the inner Window is transient for the outer Window. It works even if the Loader's Window has a visible: true declaration: in that case, until now, the Loader's Window would become visible at component creation time, before the outer Item became visible. So the test to check whether it had a transient parent did not work. We now change the delayed-visibility mechanism in QQuickWindowQmlImpl to wait for the parent Item to acquire a window of its own rather than waiting for the transient-parent-if-any to become visible. It should still take care of all the old cases too, e.g. in the Window { Window { } } case, the inner Window's QObject parent is actually the QQuickRootItem. (Amends 701255c76f671f100338a799f0194bf10e26c9d1) [ChangeLog][QtQuick][QQuickWindow] When a Window is declared inside another Item or Window, the window will not be created until the parent window is created. This allows it to have the correct transientParent and be managed as a transient window. Task-number: QTBUG-52944 Change-Id: Iaf4aafbd696f6e8dd0eec1d02db8bd181483bd07 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Prevent invalid characters being entered at the appropriate timesAndy Shaw2018-02-021-27/+9
| | | | | | | | | | | | | | | | | When a validator does not allow for certain characters to be entered, then it should not allow these to be entered in even if an input mask is set. This fixes a regression introduced in 1b21b73e89942d567c90a17a3bf7a7ecae3de258. The test modified is because this is in fact a general limitation when combining validators and input masks, when a separator is used. Whereas the original patch did allow this to be possible, this is now not possible again. Task-number: QTBUG-64616 Change-Id: Ic6a3f40a9faa7c04abc055cfc2752044fddd33a0 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Add a link to the "Using C++ Models in QML Tutorial" videoMitch Curtis2018-02-011-0/+4
| | | | | Change-Id: I1e1d8f3996bf2d187491d50a76852fb82257a42b Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* QQuickItem::stackBefore/After: print more useful warningsMitch Curtis2018-01-241-2/+4
| | | | | | | | | | | | | | | | | | | | Before this patch, you'd get the following warning: QQuickItem::stackAfter: Cannot stack after 0x7f9e668368c0, which must be a sibling After this patch, you get this warning: QQuickItem::stackAfter: Cannot stack QQuickItem_QML_131(0x7ff548f44d70, name="hoverPathDelegate", parent=0x7ff54a871c90, geometry=0,0 0x0) after QQuickItem_QML_131(0x7ff548f3c8f0, name = "hoverPathDelegate"), which must be a sibling This tells you which type caused the warning, and, if you've set it, its objectName. Change-Id: I7b20f1ac089f42d73f02bcca0382022905d0cb57 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: Do make 'Licenses and Attributions' valid for multiple Qt versionsKai Koehne2018-01-221-1/+2
| | | | | | | | | | | The Qt documentation is supposed to be valid for older Qt versions too. Anyhow, the generated attributions are only valid for the exact version the documentation was generated from, so make this explicit. Also mention since when the libraries are under LGPL3/GPL3. Change-Id: Iec8f67e5e43be456cc77283ca6d2a7ebe142f501 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Doc: Rename Renderer page to 'Scene Graph OpenGL Renderer'Kai Koehne2018-01-221-5/+6
| | | | | | | | | While the architecture might be similar for e.g. the DirectX Renderer, the details are only valid for OpenGL backend. Make this explicit by renaming the page. Change-Id: I24bf82de35099ae14eb6bfb9d58b422b476636ac Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Avoid repeated calls into thread local storage to get the animation timerLars Knoll2018-01-221-1/+1
| | | | | | | | | | Instead hold a direct pointer to the animation timer and make it's methods non static. Change-Id: I6382fd2a1c02464ddb573f0210a14c603fd932db Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: J-P Nurmi <jpnurmi@qt.io> Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Remove another call to QOpenGLContext::currentContext()Erik Verbruggen2018-01-191-1/+1
| | | | | | | .. by getting the context from the readily available state. Change-Id: Ie2819a112b31e080a865c657d0fc63cd1968e7a3 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Doc: Improve "Qt Quick Scene Graph Renderer"Kai Koehne2018-01-191-21/+21
| | | | | | | Fix some typos and grammar errors. Change-Id: I9a3fa591ada5ec299ea1277386405944138c9ddc Reviewed-by: Martin Smith <martin.smith@qt.io>
* Speed up PropertyChange state applicationSimon Hausmann2018-01-173-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every time we decode a potential binding of a PropertyChanges{} object, we call qmlContext(this) and we go through a full QQmlProperty construction (which involves property name decoding by dots and property lookups), just to determine if we're doing a binding on a property or a signal. QQmlProperty::isSignalProperty() will only return true if the property is valid and if it's a "function" type. The QQmlProperty constructor on the other hand only constructs a valid regular property if it's _not_ a function type and a signal property _has_ to start with "on" followed by an upper case character. We can copy this shortcut out into decodeBinding() to avoid the QQmlProperty construction in the common case of plain property bindings. This is also legit in the scope of group properties, as signal bindings on group properties are not supported (we always use the state's target object for signal lookup, never the group object). In addition, avoid creating a public QQmlContext for the PropertyChange object by allowing for the construction of the QQmlProperty object via the QQmlContextData, as that's the only data structure we really need. These two changes used to be separate, but they need to go together to keep the tests passing, as the property validation and warning issuing is now moved from decodeBinding() into ::actions() itself. Shaves off 1.5% off delegates_item_states.qml Task-number: QTBUG-65708 Change-Id: I32a17d815bd3495a907a51068a971eb7cb69c6ef Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix quadratic behavior in QQuickRepeater::clear(), take 2Lars Knoll2018-01-171-1/+4
| | | | | | | | | This amends 52874a0e6f739ce410c8401e19b0a9ef6d02cabf, to also fix the quadratic behavior when removing the repeaters item from their parent. Change-Id: I24ad7ca4f66a765a5e991846d65803ccf84c2cab Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Partially revert "Optimizations for Repeater::clear() and ~QQmlItem()"Lars Knoll2018-01-171-3/+3
| | | | | | | | | | | | | | | Reversing the destruction order in ~QQuickItem, and searching from the back in removeChild() wasn't such a good idea after all, as it breaks some assumptions people have about removing. We'll need to find a different solution for the quadratic behaviour coming from QQuickRepeater::clear(). This reverts parts of commit 52874a0e6f739ce410c8401e19b0a9ef6d02cabf. Change-Id: I5a6ff9f5ddd9f0f6667142dbcc568b6aba6f8ee9 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Optimizations for Repeater::clear() and ~QQmlItem()Lars Knoll2018-01-151-3/+3
| | | | | | | | | | | QQmlRepeater::clear() had quadratic complexity in the number of items, because the items where removed from the back. Fix this by searching the cache from the back as well as searching for child items to remove from the back. Change-Id: I92e491a8abf47cee9d382ef15cd2471f722fa6dd Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QSGSoftwarePixmapRenderer: Fix incorrect background coordinatesJüri Valdmann2018-01-124-9/+10
| | | | | | | | | | | | | The pixmap renderer sets up QPainter's window coordinates system but still positions the background node in device coordinates. If the window rectangle is QRect(x, y, w, h) then the background rectangle will be set to QRect(0, 0, w, h). As the rendering output is clipped to the background rectangle, this means that the image will be left with transparent bands of x pixels on the right and y pixels on the bottom. Task-number: QTBUG-62867 Change-Id: I3b2c18dafda4381b0daa64f849330f51bcc743b2 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* GridView: Fix an off-by-one offset of positioning of itemsJan Arve Sæther2018-01-101-7/+6
| | | | | | | | | | The block for finding the position for the item *before* needs to be applied for the case where visibleItems is empty too, so we separate it out. Change-Id: I60a7e3a44d01a0087970e37bf4e73b94da5ebd48 Task-number: QTBUG-49218 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Initialize member variableJesus Fernandez2018-01-101-2/+2
| | | | | | | | | >>> CID 186477: Uninitialized members (UNINIT_CTOR) >>> Non-static class member "padding" is not initialized in this Change-Id: I1861a959ec8027b62321885de5d48e6e1df1ccc4 Coverity-Id: 186477 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: state that childrenRect is read-onlyMitch Curtis2018-01-051-1/+2
| | | | | | Task-number: QTBUG-64115 Change-Id: I0246124a438328c062c37560b1b45c025078c681 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQuickAnimatedImagePrivate::setMovie: check for re-assignment; cleanupShawn Rutledge2017-12-272-71/+64
| | | | | | | | | | | There's no need to delete the movie if the same one is being re-assigned. Also, reorder, rename and clean up the variables. Followup to bb02a577f0fbf3bd2a273129e6cb57cfc9a338c8 Task-number: QTBUG-62913 Change-Id: I1fc57b411bfbd819b88be20f5933db8c13e9aba0 Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Move setVisible into QQuickItemPrivatePaolo Angelelli2017-12-242-9/+16
| | | | | Change-Id: I6bda48f5e982d8e93b8d9a604c275bc0cc0434de Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: correct Keys::shortcutOverride code snippetMitch Curtis2017-12-201-1/+1
| | | | | | | | | | | | c4eefa4a added a snippet where an onEscapePressed handler had: event.accepted = true which is unnecessary, as the documentation says that handlers for specific key events set event.accepted to true by default. Change-Id: I1a40e6e82240a517ba5059a1d5d2217cc7968302 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Check the context matcher for isDestroyed() before assigning itUlf Hermann2017-12-201-1/+2
| | | | | | | | | | Some code "resets" a custom context matcher on destruction. As destruction order of global objects is not defined, that may be after the context matcher has already been destroyed. Change-Id: I1d3869cb393c490ddb70b71a2d93578a03e2af79 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQuickItemView: Clear pending changes when refillingUlf Hermann2017-12-181-35/+41
| | | | | | | | | | | | | | | | | | | | | | | | | Generally the bufferedChanges are an "extension" of the currentChanges, which can just not be applied at the moment because we are in a layout phase. If we regenerate or clear the whole view in the mean time, the bufferedChanges become just as invalid as the currentChanges. On top of that, refilling can trigger further changes, part of which will be applied during the refilling. As that leaves us in an inconsistent state, we need to loop the refilling until no further changes are generated. As the changes might affect items that are already visible, and therefore not subject to refilling, we need to clear all the items before refilling in this case. In QTBUG-46488 things are added in the onCompleted callback of the delegates (by expanding the tree view, which translates into adding rows to the list view). Depending on where you add the new items, the list view might pick them up when iterating the model on refill() or it might create delegates for the same model entry twice. So, if that happens we need to discard the result and refill again. Task-number: QTBUG-46488 Change-Id: Ie4e0a731f7feda6aa962b6cb9a6cd5c3bf90486e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickList/GridViewPrivate::fixupPosition: don't set moveReasonShawn Rutledge2017-12-162-4/+0
| | | | | | | | | | | | | | | In QQuickItemViewPrivate::applyModelChanges(), if moveReason = QQuickItemViewPrivate::Other, then QQuickItemView::trackedPositionChanged() will fail to call d->setPosition(pos), which is normally what keeps the Flickable moving for a while. Leave the reason as-is (it will be SetIndex in this case), so as not to forget that we were actually trying to move down when the sequence window->polishItems() -> QQIV::updatePolish() -> layout() -> fixupPosition() did its part of the work of moving down. Task-number: QTBUG-62864 Change-Id: I1021e2ea39265de9e1285e2ee17c5733189ab939 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add new logging category qt.quick.window.transientShawn Rutledge2017-12-156-3/+58
| | | | | | | | | | | | | to monitor the increasing number of places from which the transient parent relationship can be detected; and a debug operator for QQuickWindow so that these log messages are more useful. [ChangeLog][QtQuick][QQuickWindow] added logging category qt.quick.window.transient to check detection of transient windows declared inside other Items and Windows Change-Id: Ic899af648765fcdc59b8da7dd1f1bed20db300f2 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Fix QSGTexture* leak in QQuickFramebufferObjectLaszlo Agocs2017-12-141-0/+1
| | | | | | | | | | | Ownership is not taken by the node. The dtor already destroys the QSGTexture correctly so follow suit when recreating the FBO due to a resize. Task-number: QTBUG-65156 Change-Id: I13a9f0332bf75a4c624ea7dd24633625ca07c8d4 Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* remove unimplemented QQuickItemPrivate::_q_windowChanged declarationShawn Rutledge2017-12-131-1/+0
| | | | | | | | It was added in 4c5445ddb0e7388247783c868925c086bdd666f7 but never implemented. Change-Id: I748295b2a1d82ed19444c0e447e1d7e88baf34b1 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Flickable: don't jump after premature movementEnding due to timerShawn Rutledge2017-12-131-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to ef8c6f6a0bf5e4c9ee41306f2df59048ab96038f: we emit movementEnding for the benefit of the user, scrollbars, decorators etc. in case the ScrollEnd phase means that movement really ended (it means the user lifted his fingers from the trackpad, but momentum events can cause the movement to continue after that). But in case movement didn't end, we don't want to have a jump when it resumes. But scrollingPhase will be true after an event with ScrollBegin phase, and false after an event with ScrollEnd, also false if the mouse is an ordinary wheel mouse without phases. So when the timer fires, if the user has not yet lifted his fingers, scrollingPhase is true, and that means scrolling isn't really ending, so we should not set vMoved to false. Setting vMoved to false will cause the drag() function to reset vData.dragStartOffset to the current dy value, which ultimately causes the jump in contentY. It should be done only when scrolling really ends. If the timer fires and scrollingPhase is false, we can be sure it really ended. But if you flick, then rest your fingers, then lift them, there is no momentum, so the final event has scroll phase ScrollEnd, and we need to run the timer one more time to detect that there are no more updates and finish the transition back to the default state (set vMoved back to false, emit signals such as movementEnded, etc.) The ultimate solution is to add another Qt::ScrollPhase enum, such as ScrollMomentum, but we should not do that in the 5.9 series. Task-number: QTBUG-63026 Change-Id: I854c52a680028cb1d43b133be65653d87a05a0b1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Handle the application state changes so items update appropriatelyAndy Shaw2017-12-112-2/+10
| | | | | | | | | | | | When the application state is no longer active, then the items should be acting as if the window deactivated in this case. This allows MouseAreas for instance to ungrab the mouse when the application goes into the background on mobile devices. Task-number: QTBUG-53036 Change-Id: I5c9a56a5fd3ad3a2ef03ff114561c671874a9391 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Fix valgrind warning about uninitialized variableLars Knoll2017-12-111-1/+3
| | | | | | | | The flaky qmltest autotest triggered these warnings quite a bit, so maybe this helps stabilize that autotest. Change-Id: Ib03a9fbbbde376296e7bea4cbd4ba2422907fe44 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Make deletion of transitions safeLars Knoll2017-12-113-23/+39
| | | | | | Task-number: QTBUG-63844 Change-Id: I65029e9039ea3db85152fc3cdefaac3deee0db6c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* grabMouse() and QQWPriv::removeGrabber(): be clear whether mouse or touchShawn Rutledge2017-12-053-41/+35
| | | | | | | | | | | | | | | | | | | | | | | The bug was that a MouseArea could be stuck in pressed state if a touch tap occurred simultaneously on a second MouseArea while the first was held pressed by the actual mouse. QQuickWindowPrivate::setMouseGrabber(QQuickItem *) had too little information to make the right choice in case the given item argument is null. It should not mean ungrab everything: in this use case, the mouse and the touchpoint can be pressing two different MouseAreas, and releasing either one should ungrab only the MouseArea that is being released. However the only place it was called with nullptr was in removeGrabber(), and in that context we are given all the information: which item to ungrab and whether we want to ungrab mouse, touch or both. It's better to have a little code duplication between QQuickItem::grabMouse() and QQuickWindowPrivate::removeGrabber() than to lose this information about which device(s) and Item to ungrab. Task-number: QTBUG-64249 Change-Id: I0710534a05f3ceeb66105a03ab0f32a61df8a522 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickListView/GridView: load items that results from model changes ↵Richard Moe Gustavsen2017-11-302-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | synchronously The current implementation created new items with default incubation mode, which is AsynchronousIfNested. But from reading the code, it seems like changes to the model were really expected to be handled synchronously, since there aren't any sections in the code that will recover from situations were requested items ends up incubating async. This is also backed by the fact that the second argument used to be a bool set to 'synchronous'. The fact that this was translated to AsynchronousIfNested later down the chain didn't seems to be taken into account. A bug with this is found in ListView when it's embedded inside an async Loader. In that case, all list items will be incubating async at startup, which is normally expected and fine. But if the model assigned to the ListView is modified before the loader has finished, async loading will also happen to the items created because of the change. And then the situation described above will occur. This patch will force any items loaded because of a model change to be synchronous. This seems to be in line with the synchronous logic that already exists. And its also quite acceptable, since changing the model before everything is completed is a corner case, and can naturally lead to some stuttering in the list view anyway. A potential for improvement on this logic is to try to recover whenever creating an item fails. But this takes a lot of work because of the way model changes are structured and stored, and can easily cause regressions. Since this is a corner case, it is probably not worth it. [ChangeLog][QtQml][ListView] Fixed a bug in ListView that sometimes make items end up with wrong geometry when changes to its model happens while the ListView is being loaded async (e.g if wrapped inside an async Loader). Task-number: QTBUG-61537 Change-Id: I8d6857beaf8ef98b02bb46282a1312749b0fb801 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQmlDelegateModel: add incubationStatus(), and use it to determine ↵Richard Moe Gustavsen2017-11-301-3/+9
| | | | | | | | | | | | | | 'requestedIndex' We used to assign the currently incubating item to 'requestedIndex' based on requested incubation mode alone. This is not sufficient, as the item can also be loaded async when the mode is AsyncIfNested. To check if the item is really loading async (and that we're not getting nullptr because of some other failure), we need to ask the incubator. Task-number: QTBUG-61537 Change-Id: Id1f458db4a7584a6b58d5bad0e7832ce4fc341dc Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQmlIntanceModel: use QQmlIncubator::IncubationMode instead of bool to ↵Richard Moe Gustavsen2017-11-306-14/+18
| | | | | | | | | | | | | | | | | | | | | | specify incubation mode The current implementation would pass a boolean to signal if asynchronous or synchronous incubation should be used to create an item. The problem with this approach is that passing 'synchronous" would translate to QQmlIncubation::AsynchronousIfNested later down the chain. This meant that even if the caller requested synchronous incubation, it could end up with asynchronous incubation anyway, e.g if an async parent incubator was active at the time of the call. And this can easily come as an unhandled supprise for the caller, and as such, cause unforseen bugs. This patch is a first of a set of patches that is done to fix the bug reported in the task below. It will not change any behavior, it is written to preserve the logic exactly as it were, just as a preparation for subsequent patches. It makes it explicit at the call location what incubation mode will be used, and especially make it clear whenever the AsynchronousIfNested flag is in play. Task-number: QTBUG-61537 Change-Id: I8b3ba5438ebb2cd59983a098bd8ceeeb844da87b Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* don't get confused about the grabber during replayDelayedPressShawn Rutledge2017-11-292-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | If a ListView with pressDelay contains a MouseArea in a delegate, and you tap the MouseArea on a touchscreen, QQuickFlickablePrivate::replayDelayedPress() sends a saved copy of the original QMouseEvent, and then a synthetic release, without marking it as synthetic. (QQuickFlickable is not touch-aware in any way: it thinks the mouse events it receives are real ones.) As a result of sending the delayed press through, QQuickWindowPrivate::setMouseGrabber() is called and sets the touchpoint's grabber to the MouseArea, but does not set the core pointer's eventpoint's grabber. Flickable then ungrabs for itself, so we have to ensure that the ungrab affects either the actual mouse or the synth-mouse, whichever was in use. Then because the synthetic release is not known to come from a touchscreen, QQuickWindowPrivate::deliverMouseEvent() was checking the core pointer's grabber and concluding that there is no grabber. In such a case, it now checks whether touchMouseId is set, meaning that we are somewhere between sending a synthesized press and release, gets the touchpoint's grabber (which is MouseArea, because it didn't reject the press), and sends the release there. Task-number: QTBUG-61144 Change-Id: I494873e48af179bc63b618e881ba469b97dadf4d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix crash when moving items during asynchronous creationJoni Poikelin2017-11-281-2/+9
| | | | | | | | | | | | | | | In complicated cases where the model moves rows around while the view is running slow (perhaps during high CPU load), there were cases when Repeater would call movedItem->stackBefore(deleteableItem), but deleteable items can be null, so there was often an error QQuickItem::stackBefore: Cannot stack before 0x0, which must be a sibling and occasionally a crash. Now we check both the callee and the parameter to stackBefore to make sure neither of them are null. Task-number: QTBUG-54859 Change-Id: I45a8b2939c16b9bbe3a802ddd348dc55f51061a7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge "Merge remote-tracking branch 'origin/5.9.3' into 5.9" into ↵Liang Qi2017-11-251-4/+5
|\ | | | | | | refs/staging/5.9
| * Merge remote-tracking branch 'origin/5.9.3' into 5.9Liang Qi2017-11-231-4/+5
| |\ | | | | | | | | | Change-Id: Ic6457df47bed359fd43653e73726f1896944241c
| | * Fix crash when accessing pixmap on default QSGSoftwareInternalImageNodev5.9.3Allan Sandfeld Jensen2017-11-171-4/+5
| | | | | | | | | | | | | | | | | | | | | Task-number: QTBUG-64562 Change-Id: I52e07b0d8b7a5d1cc960431dcbd1a90dd3e7e518 Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | | Software Adaptation: Fix cliping logic error with empty clip regionsAndy Nichols2017-11-231-2/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous fix for nested clip regions introduced a regression which broke nested clipping cases that involved one of the clip nodes being null regions because they were offscreen. The clip region stack can either have an null QRegion or be empty as an initial state (depends on what is being rendered). We made a special check for these two states, but it is not enough to check if the top item is null for the null region case beacuse at any point in time a null clip region node could have been added. So to fix this the null initial state also requires a count of 1. Task-number: QTBUG-63743 Change-Id: Ib0d17026f1d5a663e819412e11d25d9ad8b445ff Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | watch for the actual render window if there is a QQuickRenderControlMarco Martin2017-11-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | if the scene is rendered by a QQuickRenderControl and we have a different target window (for instance QQuickWidget) we check the target window of the render control instead of the own window, this fixes window keyboard shortcuts for QQuickWidget Task-number: QTBUG-64548 Change-Id: I7614be580f2a707c752189e4c9b53a5d5f0159d7 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-23 17:46:32 +0000