1. 12 Jun, 2014 2 commits
  2. 15 May, 2014 1 commit
  3. 14 May, 2014 1 commit
  4. 02 Apr, 2014 1 commit
  5. 27 Mar, 2014 1 commit
  6. 20 Mar, 2014 2 commits
    • Robin Burchell's avatar
      Merge pull request #60 from sletta/master · 6ed4988a
      Robin Burchell authored
      [qtdeclarative] Make sure the visibility state is the same in GUI and Render threads.
      6ed4988a
    • sletta's avatar
      [qtdeclarative] Make sure the visibility state is the same in GUI and Render threads. · 6e6ff274
      sletta authored
      show() would add a window to the GUI thread's list of windows.
      handleExposure() which is called asynchronously from show() would add
      it to the render thread's list. hide() would remove it from both GUI
      and render in one go. That meant that for a short while after
      win1.show(), win2.hide(), the GUI thread would have an entry in its
      list (from show()) while the render thread had none (not yet delivered
      through handleExposure()).
      
      This had some side effects. If we entered polishAndSync() at this
      time, the GUI thread would enter the sync lock and post an event, but
      as the render thread doesn't track any windows, it would never pick it
      up and the system would deadlock. Also, if an incubation controller
      was awaiting the incubation signal (as told via
      interleaveIncubation()) it would never get it.
      
      Also, a separate thing, but related. To make sure nobody is waiting
      for an incubation signal when the render thread stops, emit an
      incubation signal after the render loop might have stopped, just to be
      on the safe side.
      
      Change-Id: I8d88bb149370f053be9c53cede59eb9920456983
      6e6ff274
  7. 18 Mar, 2014 2 commits
    • Robin Burchell's avatar
      Merge pull request #59 from special/qqmlincubator-loop · 312b185b
      Robin Burchell authored
      [qtdeclarative] Fix infinite loop in QQmlIncubator::forceCompletion
      312b185b
    • Albert Astals Cid's avatar
      Fix infinite loop in QQmlIncubator::forceCompletion · b717e380
      Albert Astals Cid authored
      Without this change I'm getting this backtrace
      3  0x4025b9f2 in QQmlIncubatorPrivate::incubate (this=0x18daa78, i=...) at qml/qqmlincubator.cpp:273
      4  0x4025c1c2 in QQmlIncubator::forceCompletion (this=0x1527360) at qml/qqmlincubator.cpp:592
      5  0x404e1626 in QQuickVisualDataModelPrivate::object (this=this@entry=0x13909f8, group=QQuickListCompositor::Default, index=index@entry=1, asynchronous=asynchronous@entry=false) at items/qquickvisualdatamodel.cpp:900
      6  0x404e1f7e in QQuickVisualDataModel::item (this=<optimized out>, index=1, asynchronous=<optimized out>) at items/qquickvisualdatamodel.cpp:968
      Note: This is with patched 5.0.x, change QQuickVisualDataModel to QQmlDelegateModel for >= 5.1
            and line numbers may be a bit off
      
      What is happening:
      QQmlIncubator::forceCompletion is doing
          while (Loading == status()) {
              while (Loading == status() && !d->waitingFor.isEmpty())
                  static_cast<QQmlIncubatorPrivate *>(d->waitingFor.first())->incubate(i);
              if (Loading == status())
                  d->incubate(i);
          }
      Calling QQmlIncubatorPrivate::incubate on the first item of d->waitingFor
      
      Then, that item is getting to QQmlIncubatorPrivate::incubate and happens that
      progress is QQmlIncubatorPrivate::Completed and waitingFor is not empty,
      so the only thing that QQmlIncubatorPrivate::incubate ends up doing is
      calling a few calls over vmeGuard and returning, that way the inner
      waitingFor items never finishe incubating and you end up in an inifite loop inside
              while (Loading == status() && !d->waitingFor.isEmpty())
                  static_cast<QQmlIncubatorPrivate *>(d->waitingFor.first())->incubate(i);
      
      This patch basically replaces this loop with a loop that does
              while (QQmlIncubator::Loading == status && !waitingFor.isEmpty())
                  static_cast<QQmlIncubatorPrivate *>(waitingFor.first())->forceCompletion(i);
      
      This way we make sure we incubate the waitingFor items of our waitingFor items
      
      Change-Id: I4298efc7ba9d8af624bb138e64b92a40ed4c4dc9
      Reviewed-by: 's avatarLars Knoll <lars.knoll@digia.com>
      b717e380
  8. 17 Mar, 2014 2 commits
  9. 14 Mar, 2014 1 commit
  10. 13 Mar, 2014 3 commits
    • Richard Braakman's avatar
      [qtdeclarative] Fix memory corruption bug · 3cfbd9d3
      Richard Braakman authored
      In QQmlData::destroyed(), release the compiledData after
      destroying the context instead of before. The context
      contains bindings which may contain references to the
      compiledData. (At least with V4 bindings)
      
      This might cause heap corruption in QV4Bindings::Binding::disconnect()
      because it uses values from 'program' (one of the datas[] values
      from a QQmlCompiledData) to possibly modify memory via sub->setActive().
      
      The reads from a freed program are easily reproduced (just start
      an app under lipstick and then close it; detected with valgrind).
      I haven't witnessed any heap corruption from this but it may be
      behind the occasional crashes of lipstick.
      3cfbd9d3
    • Robin Burchell's avatar
      Merge pull request #57 from mbrasser-jolla/master · 63f1314c
      Robin Burchell authored
      QQuickTimeLine: add missing time checks
      63f1314c
    • Robin Burchell's avatar
      Merge pull request #55 from martinjones/master · 46908bfd
      Robin Burchell authored
      [qtdeclarative] Don't crash due to KeyRelease on an unloaded Item.
      46908bfd
  11. 11 Mar, 2014 1 commit
    • J-P Nurmi's avatar
      QQuickTimeLine: add missing time checks · c86813b5
      J-P Nurmi authored
      The same check is done in QQuickTimeLine::pause(), move() and moveBy(),
      where the time is passed as an argument. QQuickTimeLine::accel() and
      accelDistance() calculate the time based on velocity and acceleration
      or distance. With tiny values this calculation can result to a negative
      time due to integer overflow.
      
      Task-number: QTBUG-35046
      Change-Id: I000e73d3f787375946e8f87a5d24153ae919bc8d
      Reviewed-by: 's avatarMichael Brasser <michael.brasser@live.com>
      c86813b5
  12. 07 Mar, 2014 1 commit
  13. 27 Feb, 2014 1 commit
  14. 26 Feb, 2014 1 commit
    • sletta's avatar
      [qtdeclarative] Ensure that ShaderEffectSource's texture has correct parameters. · d5ea4b4f
      sletta authored
      The provider is created on demand in textureProvider(), but its
      parameters are set in updatePaintNode() so if updatePaintNode() was
      called before a consumer asked for the texture provider, they wouldn't
      be set until the next time updatePaintNode() was called.
      
      Change-Id: Iff866d50a8fe16f3d371cb8e590528f5f8c5ee61
      d5ea4b4f
  15. 04 Feb, 2014 4 commits
  16. 21 Jan, 2014 2 commits
  17. 08 Jan, 2014 1 commit
  18. 17 Dec, 2013 1 commit
  19. 13 Dec, 2013 7 commits
  20. 12 Dec, 2013 1 commit
    • martinjones's avatar
      Fix Flickable StopAtBounds drag over, back, over behavior. · b8da4427
      martinjones authored
      A Flickable with StopAtBounds failed when:
      1. position on a boundary.
      Without lifting your finger:
      2. attempt to drag beyond the boundary -> doesn't drag
      3. drag back to initiate dragging
      4. attempt to quickly drag beyond the boundary.
      
      After 4, the view should be back on the boundary, but it could get
      stuck a little short of the boundary.
      
      Change-Id: I9bfbb4293f4d464bddb97c5c37e9bb91ed7d48e4
      Reviewed-by: 's avatarRobin Burchell <robin+qt@viroteck.net>
      b8da4427
  21. 05 Dec, 2013 1 commit
  22. 21 Nov, 2013 1 commit
  23. 12 Nov, 2013 1 commit
  24. 08 Nov, 2013 1 commit