Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-56601

Don't use custom animators for busy indicators and indeterminate progress bars

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: P1: Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 5.8.0 Beta
    • Component/s: Quick: Controls 2
    • Labels:
      None

      Description

      When the animator internals were redone (https://codereview.qt-project.org/#/c/168949/), QQC2 broke and ended up blocking the entire Qt5 integration. The change was eventually reverted for the time being, but we want to get it back in, of course. It is possible to animate scene graph nodes in the render thread without using animators. The use of custom animators relies on private APIs, and doesn't give much benefits. The threaded animation example in qtdeclarative illustrates how to implement such animations in a simple way: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/scenegraph/threadedanimation. This is the way QQC2 should also drive its busy indicator animations. This won't rely on the private APIs, and the code becomes simpler.

      From #qt-graphics:

      [14:31:10] <jpnurmi> sletta: ping?
      [14:32:30] <jpnurmi> sletta: assert failure when stopping a running animator, after the internals were redone: https://bugreports.qt.io/browse/QTBUG-56572
      [14:35:07] <jpnurmi> sletta: and since the CI now uses qt5.git for integrations, the internal api changes are now unfortunately blocking us to adapt qqc2 to the new api
      [14:36:50] <jpnurmi> sletta: restoring a temporary compatibility api just to make it possible to integrate qt5.git and then adapt qqc2 would be easy, but then the aforementioned assert failure gets in the way and makes qqc2 tests fail..
      [14:37:19] <jpnurmi> => https://codereview.qt-project.org/#/c/174070/
      [15:07:59] <sletta> jpnurmi: that kinda sux, but ok
      [15:09:25] <sletta> jpnurmi: how come the decision to use internal animator api from controls anyway?
      [15:10:07] <jpnurmi> sletta: because the type of animations we have are impossible to write in QML with the built-in set of animators
      [15:11:20] <sletta> should have just done an animated sg item then
      [15:11:40] <jpnurmi> having to sync with the internal api changes is a small price to pay to get super light-weight threaded animators ;)
      [15:12:00] <sletta> a plain sg item would also have given you that
      [15:12:15] <sletta> without the api hurdle, and without integrating with a pretty messed up implementation
      [15:13:30] <jpnurmi> what are you referring to with a "plain sg item"?
      [15:14:16] <sletta> The code there is using updatePaintNode to create nodes and then animating them. So the use of animator internals there gives you very little
      [15:14:26] <sletta> you can animate QSGNodes directly
      [15:16:22] <sletta> like here: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/scenegraph/threadedanimation
      [15:17:16] <jpnurmi> sletta: ok, thanks for the tip
      [15:18:08] <jpnurmi> we'll refactor them as soon as i have some spare time :)
      

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jpnurmi J-P Nurmi
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: