aboutsummaryrefslogtreecommitdiffstats
path: root/src/quicktemplates2/qquickdeferredexecute_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Do not execute a deferred property when component complete is disabledThomas Hartmann2018-03-261-0/+5
| | | | | | | | | | | The Qt Quick Designer disables component complete and completes the items manually at a later point. To avoid undefined behavior on items quickBeginDeferred() should not be called if completion is disabled. Task-number: QTBUG-67152 Change-Id: Ibf5c6c834436889cfda7862ea7b327731a026cf9 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* Fix deferred executionJ-P Nurmi2017-12-211-3/+6
| | | | | | | | | | | | | | | | | | If the QML engine refuses to defer execution of a delegate (it contains an ID), we must make sure to cancel any pending deferred execution for the same delegate. Otherwise, we may end up overriding a custom (non- deferred) delegate with a default (deferred) delegate. This patch adds a new test style "identified" to tst_customization. This style contains delegates with IDs so we can test the behavior with IDs in base styles. Furthermore, overriding delegates is now tested in various ways (with and without IDs in the base and custom styles) in a separate test method. This is done by generating QML code to override delegates with dummy Item instances with appropriate IDs and names. Task-number: QTBUG-65341 Change-Id: Ie6dca287cb74672004d9d8f599760b9d32c3a380 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Migitate the performance regression caused by deferred executionJ-P Nurmi2017-12-121-8/+14
| | | | | | | | | | | | | | | | | | 458eb65f7 introduced a performance regression. Before 458eb65f7, qmlbench delegates_button.qml results were around 40 frames on a TX1. After 458eb65f, it dropped to 32. This patch is unfortunately not able to bring it on the original level, but at least improves the results to 37. For QQuickText, it is extremely important that implicitWidth() gets called before the component is completed, to avoid doing implicit size calculation multiple times. Deferred execution caused a performance regression by creating contentItem in "one go". We need to split the deferred execution to two parts so that bindings get first setup, and later enabled upon completion. This way, we utilize QQuickText's performance optimization for implicit size calculation. Task-number: QTBUG-50992 Change-Id: I4bf00af71b6d7dbf1d4b58b00fe547c6c321f8ed Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Buttons: defer the execution of the delegatesJ-P Nurmi2017-12-111-0/+79
In practice, deferring the execution of the delegates (until accessed) means that the default delegate item does not get created at all, when a custom control replaces it at construction time. Button { background: Rectangle { ... } } Before, such custom Button would never be faster than the original one, because the default delegate was first created and then thrown away at construction time. Originally, this was not considered a huge problem, because the plan was to keep the default delegates so light- weight that it wouldn't matter. However, then came the fancy styles with shadows and effects and thus, heavier default delegates. There's also a growing demand for more features, and the default delegates are slowly getting heavier... Now, after this patch, if you replace a heavy default delegate with a light and simple custom delegate, the result is a much faster control. For example, replacing Material style Button's background, which has a shadow effect, with a plain Rectangle gives a ~10x boost, because the default background with its heavy shadow effect is not executed at all. At the same time, deferring the execution of the default delegates avoids troubles with asynchronous incubation, because we don't need to destroy an object in the middle of the incubation process. Task-number: QTBUG-50992 Change-Id: I2274bff99b9ff126d3748278d58d859222910c98 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>