1. 16 Apr, 2019 2 commits
  2. 07 Mar, 2019 1 commit
  3. 15 Feb, 2019 1 commit
  4. 11 Jan, 2019 2 commits
  5. 25 May, 2018 1 commit
  6. 24 May, 2018 1 commit
    • Simon Hausmann's avatar
      Fix crash when modifying list model in worker thread · e26ef5d3
      Simon Hausmann authored
      If we call get() on a model in a worker thread, we may end up creating a
      ModelNodeMetaObject (aka cacheObject). Subsequent mutation of properties
      may make us end up in emitDirectNotifies(). However since we can't have
      bindings in there, we should shortcut/suppress the notify emission, which
      we can do by checking ddata->context via qmlEngine(). The previous code
      crashed when qmlEngine() return a null pointer but
      QQmlEnginePrivate::get(const QQmlEngine *) would attempt to dereference
      the parameter.
      
      Started-by: Slava Monich<slava.monich@jolla.com>
      Change-Id: I880619c686436c053692faafa5dba2c96c2ace96
      Reviewed-by: 's avatarRobin Burchell <robin.burchell@crimson.no>
      Reviewed-by: Slava Monich's avatarSlava Monich <slava.monich@jolla.com>
      e26ef5d3
  7. 30 Apr, 2018 3 commits
  8. 27 Apr, 2018 2 commits
  9. 15 Mar, 2018 1 commit
    • Erik Verbruggen's avatar
      Fix JITted code for jump strict-not-equal undefined on 32bit · e2218f8b
      Erik Verbruggen authored
      The generated code for jump-on-strict-not-equal-undefined used the
      same logic (but with inverted conditions) as the equal case. For
      equality, one can jump to else if the value parts are not the same.
      So, for not-equal, if the value parts are the same, it would jump
      to the else block if they are the same. Meaning, an encoded int
      value of 0 (which is strict-not-equal to undefined) would end up
      being evaluated as equal.
      
      Task-number: QTBUG-66832
      Change-Id: Id27bb44eccbf39608ae8cebab634c8bcd4c8adfc
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      e2218f8b
  10. 26 Feb, 2018 1 commit
    • Simon Hausmann's avatar
      Allow setting values in value type group properties in "on" assignments · 10647ce9
      Simon Hausmann authored
      Assigning to a group property inside a property value source or
      interceptor as part of an "on assignment" is perfectly valid. That is
      because while "color" is a value type property, the on assignment means
      we're actually setting easing.type (in the example and test) on the
      property value source, not the color, and that one is a QObject. The
      same goes for interceptors.
      
       Conflicts:
      	src/qml/compiler/qqmlpropertyvalidator.cpp
      	src/qml/qml/qqmlvmemetaobject_p.h
      	tests/auto/qml/qqmllanguage/tst_qqmllanguage.cpp
      
      Change-Id: I505a658977a578894d6dfb00bf5c65b41e42b12f
      Task-number: QTBUG-56600
      Reviewed-by: 's avatarMichael Brasser <michael.brasser@live.com>
      (cherry picked from commit 2659c308792967322564b5088e0e21bb371e0283)
      10647ce9
  11. 23 Feb, 2018 1 commit
    • Simon Hausmann's avatar
      Fix ListModel.get(idx) == ListModel.get(idx) · 0e7533fc
      Simon Hausmann authored
      This is a regression introduced with commit
      4876ea6a. Where we previously always
      returned the same JS object, we would afterwards return a new JS object
      for every invocation, which breaks reference comparison. As we store the
      JS wrapper for the list element in the QQmlData->jsWrapper we can avoid
      repeated allocations. In order for that wrapper to keep working after
      modifications (insertion, etc.) to the list model, we have to replace
      the static element index with a reference to the node model meta-object,
      which also has an element index that however is kept up-to-date by the
      list model itself.
      
       Conflicts:
      	src/qml/types/qqmllistmodel_p_p.h
      
      Change-Id: I4368de6b6d86687fe96fbf73bd60b80b69d7b058
      Task-number: QTBUG-52017
      Reviewed-by: 's avatarMichael Brasser <michael.brasser@live.com>
      (cherry picked from commit 44a89492b49f23a975377795dbb7a48916cb5081)
      Reviewed-by: 's avatarMitch Curtis <mitch.curtis@qt.io>
      0e7533fc
  12. 22 Feb, 2018 1 commit
    • Erik Verbruggen's avatar
      Fix 2 use-after-free problems in the ListModel · 942b7935
      Erik Verbruggen authored
      This is a combination of 2 commits that went into 5.9. They cannot be
      cherry-picked however, because some c++11 constructs were used. Hence
      this combo commit, which is a squashed version of those two commits that
      have the c++11 bits replaced by Good Old boilerplate code.
      
      Original commit 1 (e29ffa17):
      
      Fix use-after-free when removing elements from a ListModel
      
      Detaching delegate instances from model items is done after the
      destruction of said model items. The problem is that after the model
      item is destroyed, it will emit a change/destroyed signal. As the
      delegate is still referencing the item, this will result in a
      use-after-free. To provent that, the items are kept around until after
      everyone (notably the delegate model) has been notified of the removal.
      
      [ChangeLog][Qt][Qml] Fix possible use-after-free when removing items from a ListModel through JavaScript.
      
      Original commit 2 (163c5157):
      
      Fix use-after-free when clear()ing all elements from a ListModel
      
      Same problem as the problem with remove(), so now clear will call into
      remove to do the correct thing.
      
      [ChangeLog][Qt][Qml] Fix possible use-after-free when clearing all items from a ListModel through JavaScript.
      
      Task-number: QTBUG-63383
      Change-Id: I9a6bdf65da63b33833f18c80e74ad7bb93409627
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      942b7935
  13. 13 Feb, 2018 1 commit
    • Simon Hausmann's avatar
      Fix memory leak with ListModel.get · f8edd75b
      Simon Hausmann authored
      This is a regression introduced with commit
      3cc589c9, which in turn fixed a leak
      with QV4::QObjectWrapper objects. Unfortunately the allocate() call into
      the persistent (weak) value storage in the list model introduced a leak
      of the weak value itself. This is fixed by replacing the free standing
      weak value allocation with the use of the existing jsWrapper weak value
      in the declarative data (QQmlData). That weak value is freed property in
      the destroy() method of the QV4::QObjectWRapper. The extra QQmlData
      allocation is hidden behind a unified allocation, similar to what we do
      in void QQmlType::create(QObject **, void **, size_t) const.
      
      Task-number: QTBUG-66189
      Change-Id: I5351e3e484542709a6b210e84aa19b14d28e11ad
      Reviewed-by: 's avatarLars Knoll <lars.knoll@qt.io>
      (cherry picked from commit 22d43f74e264626d0c28654c42c91839f9de45b5)
      Reviewed-by: 's avatarErik Verbruggen <erik.verbruggen@qt.io>
      f8edd75b
  14. 17 Nov, 2017 2 commits
  15. 16 Nov, 2017 1 commit
    • Milian Wolff's avatar
      Fix performance issues when handling layout changed in Quick item views · e38a98ad
      Milian Wolff authored
      When the layout changes, we mark all rows as changed but do not track
      where the individual rows get moved.
      
      The only reason why one would want to track the moves is to persist
      the current item selection across a layout change. But even the previous
      code did not achieve that. I'll create a follow up patch to this one
      that also implements this behavior as seen in Qt Widget item views.
      
      Note that removing this code brings a tremendous performance win
      on larger models. The repeated calls to _q_itemsMoved triggered O(n^2)
      behavior in the number of top items in the model. Even with "only"
      tens of thousands of items in the model, a layout change became very
      costly and took seconds on a beefy modern desktop machine.
      
      Calling _q_itemsMoved in a loop is bad because it:
      
      - leads to O(N^2) behavior within QQmlChangeSet when merging the small
        moves into the item view's current change set
      - potentially triggers tons of binding/property updates when the cached
        model indices are updated in _q_itemsMoved
      
      Removing this slow path, I did not yet find a behavior change to the
      previous code. Instead, it just does it all much faster.
      
      Change-Id: I67fa99a1c5d8e05d17497d29391da9458bd9bdd0
      Task-number: QTBUG-51638
      Task-number: QTBUG-45674
      Task-number: QTBUG-53677
      Reviewed-by: 's avatarDaniel Vrátil <daniel.vratil@kdab.com>
      Reviewed-by: 's avatarRobin Burchell <robin.burchell@viroteck.net>
      (cherry picked from 84f61dd2)
      Reviewed-by: 's avatarShawn Rutledge <shawn.rutledge@qt.io>
      Reviewed-by: 's avatarUlf Hermann <ulf.hermann@qt.io>
      e38a98ad
  16. 08 Nov, 2017 1 commit
  17. 21 Sep, 2017 1 commit
  18. 15 Sep, 2017 1 commit
  19. 14 Sep, 2017 1 commit
    • Andrew den Exter's avatar
      [qtdeclarative] Add an environment variable to disable use of BGRA textures.... · c9a3870b
      Andrew den Exter authored
      [qtdeclarative] Add an environment variable to disable use of BGRA textures. Contributes to JB#39372
      
      Some hardware while supporting BGRA textures has extremely slow
      upload times.  Add an environment variable which will force
      the use of RGBA textures instead.
      
      Also try and claw back some of the time lost converting from BGRA
      to RGBA by avoiding a coversion to an intermediate
      RGBA32_Premultiplied image from non 32-bit formats.
      c9a3870b
  20. 12 Sep, 2017 1 commit
  21. 07 Sep, 2017 1 commit
  22. 06 Sep, 2017 2 commits
    • Simon Hausmann's avatar
      Fix QNX build on Windows · a8cff0a4
      Simon Hausmann authored
      Configure on Windows in Qt 5.6 does not detect the target gcc version
      correctly and reports the host gcc version instead. That means we'll end
      up enabling -fno-lifetime-dse with a gcc version that doesn't support it
      and consequently fail to build.
      
      Since in the 5.6 branch we only support QNX 6 and we know that the gcc
      version is 4.7 and thus not affected by the DSE problem, we might as
      well unconditionally disable the workaround there.
      
      This change is only for 5.6 as 5.8/5.9 and newer detect the gcc version
      correctly _and_ don't need the -fno-lifetime-dse workaround anymore.
      
      Task-number: QTBUG-62820
      Change-Id: I55baf532a9126eb2f8c5f11858d52cccad6c355b
      Reviewed-by: 's avatarSami Nurmenniemi <sami.nurmenniemi@qt.io>
      Reviewed-by: 's avatarOswald Buddenhagen <oswald.buddenhagen@qt.io>
      a8cff0a4
    • Jani Heikkinen's avatar
      Add change file for Qt 5.6.3 · 6eaaedc6
      Jani Heikkinen authored
      Task-number: QTBUG-62707
      Change-Id: I5ff6ddc2dfb1d495f20e257cbd014232cac335b7
      Reviewed-by: 's avatarShawn Rutledge <shawn.rutledge@qt.io>
      (cherry picked from commit fb52a593)
      6eaaedc6
  23. 31 Aug, 2017 1 commit
  24. 30 Aug, 2017 1 commit
  25. 15 Aug, 2017 1 commit
  26. 11 Aug, 2017 1 commit
  27. 27 Jul, 2017 2 commits
  28. 02 Jun, 2017 1 commit
  29. 01 Jun, 2017 2 commits
  30. 16 May, 2017 1 commit
  31. 12 May, 2017 1 commit