| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This moves the Layouts types into a new library and is meant to make
them availabe to the QML compiler at some point in the future.
Change-Id: I9b2b31a78b0e9ca8b6c0db1fc9272d9941c61814
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tricky cases of setting layout width based on parent layout width
were leading to infinite recursive loop of layout size calculation
(see the attached example in the related Jira task).
Initially the QQuickGridLayoutBase::rearrange() method already had
a recurse check, but it seemed to happen too late, so that the
recursive calls kept happening from the ensureLayoutItemsUpdated()
calls.
This commit moves the recursion check up, so that it's actually
executed before we have a chance to get to the next level of recursion.
Pick-to: 5.15 6.0
Fixes: QTBUG-87253
Change-Id: I473ee219e7b5b13547e33ebbd3a6d884de2c7d45
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was especially noticeable when a Repeater was populating the
children of a layout, and its model was dynamically changed: When the
model was changed, the repeater removed one item at a time until all
items were removed, then applied the new model and then added all the
new items for the new model.
The layout reacted to that by doing a full sync of the QML layout into
the internal gridlayout engine each time an item got removed or added.
For very large layouts (or layouts that have complex size hints to
calculate), this caused a major slowdown.
This patch fixes that by postponing the sync until we get a
updatePolish(), basically replacing most calls to updateLayoutItems()
(which does the sync) with a call to invalidate() (which schedules a
polish). It will also get rid of some binding loop warnings due to this
change.
This means that there is a small change in behavior:
impicitWidth, implicitHeight and Layout.{min,max}imum{Width,Height}
might in some cases be incorrect until the updatePolish() have been
done. (This is however consistent with how Row/Column/Grid behaves)
The creation test in qmlbench was quite simple, so it did not suffer
from the most severe performance issues, but we did not regress:
> compareresults:
auto/creation/layouts/delegates_rowlayout.qml: improvement by 3.91%
auto/creation/layouts/delegates_columnlayout.qml: improvement by 6.59%
auto/creation/layouts/delegates_gridlayout.qml: improvement by 1.83%
Overall average of differences: 4.11%
And for the gridlayout_large.qml (Repeater with 1000 dynamically
changing items):
> compareresults:
auto/layouts/gridlayout_large.qml: improvement by 66477.78%
Overall average of differences: 66477.78%
[ChangeLog][Qt Quick Layouts] Performance improvements to Qt Quick
Layouts. This has the small side-effect that size hints
(implicitWidth/implicithHeight etc) changes are not immediately emitted
after a layout has been modified (e.g item added)
Pick-to: 5.15
Fixes: QTBUG-71839
Fixes: QTBUG-65121
Fixes: QTBUG-66017
Change-Id: I6922efe449134246df66b177992e4442747bc8fb
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
| |
Pick-to: 5.15
Change-Id: I4db3ebb02a5b541ca8e50e65b9056d398570e331
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/imports/qtqml/plugin.cpp
src/qml/qml/qqml.h
src/qml/qml/qqmlmetatype.cpp
src/qml/qml/qqmlmetatype_p.h
src/qml/qml/qqmltypeloader.cpp
src/qml/types/qqmlbind.cpp
src/quick/items/qquickitemsmodule.cpp
tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp
Change-Id: I52548938a582cb6510271ed4bc3a9aa0c3c11df6
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/qml/jsruntime/qv4engine.cpp
Change-Id: I61f41672e2dfe7e542ca30fed5f173d0a9ee3412
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This happened because of that QQuickText is ill-behaving: When the width
on a QQuickText with word wrap enabled is changed to something less than
its implicitWidth, its implicitHeight is changed to reflect the height
it needs in order to fit all lines. This will cause the layout to be
invalidated, and rearranged again.
However, at the same time it will also change its implicitWidth actually
become wider than its initial implicitWidth (this seems to be a bug). So
the next time it is rearranged it will actually be wide enough so that
it doesn't need to wrap. This again will cause its implicitWidth and
implicitHeight to change to reflect that only one line is needed, which
again will cause it to rearrange, but since the item has a too small
width for that it will again change the implicitHeight to reflect that
it needs more lines.....
This went on forever until there was a stack overflow. In addition it
also caused an endless (that is, if it didn't stack overflow)
updatePolish()/polish() loop (basically polish() was called from within
updatePolish() continuously).
To make the layout more robust for such "ill-behaving" items we have to
add one recursion guard, and one polish-loop guard.
Change-Id: I9f752ed320a100c8d0f0fd340347a556e63318e5
Task-number: QTBUG-73683
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |\| |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/qml/types/qqmlbind.cpp
Change-Id: Ib992d1a7ac6c1a96d39819be6f23955dc31b44b2
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We now print a warning and try to gracefully handle it
Change-Id: I66e79fe918808f5fede78a23df50e9e95b7b832d
Fixes: QTBUG-67204
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/auto/qml/qqmltypeloader/tst_qqmltypeloader.cpp
Change-Id: I1c0c7c44053bf3d5f8f9723662bd0fe67253c8ae
|
| | |
| |
| |
| |
| |
| | |
Change-Id: I3ac473b3d46ff1f898c1607deb6ad3d586753244
Fixes: QTBUG-79359
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |/
|
|
|
|
|
| |
from left ro right => from left to right
Change-Id: Id7386a89438f74573bdb4b43702eadabb6805e50
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
We get several bug reports due to this mistake. Print a warning about
it and that it *might* eat your cats.
Task-number: QTBUG-63303
Change-Id: I0b1ae21dc4419efee88623765a8d6dd302fbc1f4
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
| |
|
|
|
| |
Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
We now have file & line number information pointing us to the location of the
faulty child. Also take the effort to split the message into two, so
it's clear which property is faulty (and which the value is
representing).
Change-Id: I8e515feeaf8fa1decf8aaf7adf0a02cce7aec0ea
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
The attached isRowSet and isColumnSet check for values >= 0, and
row/column getters also enforce a minimum return value of 0, so it is
impossible for us to get a negative value for row/column if either of these is
set -- and we can simply call the getter and rely on it to return 0 in
the unset case.
Change-Id: Iec80e7d7cf3738cf0a81e90b027ffe41e0f57369
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When deleting a layout with children, it ends up in ~QQuickItem(), which in
turn will call setParentItem(0). setParentItem(0) will in turn call
setEffectiveVisibleRecur(), which will recurse down all its descendants.
Therefore, deleting a top level layout might trigger item change listeners
for *all* its descendants, not only its direct children.
This behavior might even cause crashes: The visibility changes will then
trigger an invalidation of the layout, which will propagate up the parent
hierarchy, and potentially call invalidate() on a partially-destroyed
layout, which then might crash.
Change-Id: I48e11d57f69e9011ced6c3a0b51e3d89b24ad5c1
Task-number: QTBUG-55103
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Signal connections are expensive: even with qmlobject_connect, there's a bunch
of memory allocation. By avoiding the signal connections, we can do the same
thing essentially, a little faster.
This gives me another 15-20 RowLayout instances per frame when testing with
RowLayout containing 5 Rectangles on qmlbench (from ~139 to ~155 ops/frame).
Change-Id: I4448a28128dc251e40b6b06d642bae716af212f4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/quick/items/qquickitemsmodule.cpp
tests/auto/quick/rendernode/tst_rendernode.cpp
Change-Id: I90582df69feb95a4e4aafb0b9793c23714654f19
|
| | |
| |
| |
| |
| |
| |
| |
| | |
52e1044a1a22525b960d9e1d336ac06c4f39e6d5 in qtquickcontrols missed
this.
Change-Id: Ie104c421e34d4d2a13a88864a279eb65738bd5a8
Reviewed-by: Topi Reiniö <topi.reinio@theqtcompany.com>
|
| |/
|
|
|
|
|
|
|
| |
This is significantly faster, especially with a large number of items and
signals. For a RowLayout with 5 child items, I go from being able to create ~95
per frame to ~145 per frame on a 2011 mbp.
Change-Id: I2c09078573a745b6d275931785de548364604a85
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
| |
These constexpr functions can be inlined, and the compiler can be a bit
smarter with code generation.
Change-Id: I4ea87c794dd8e375749e18d273d01bb848231113
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
This is in order for it to be available without having to install
Qt Quick Controls
Change-Id: I3f0d0dc108829947cd189b7861944e556e00cef3
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
|
