Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. How does the scene is updated on screen from QML.??
Forum Updated to NodeBB v4.3 + New Features

How does the scene is updated on screen from QML.??

Scheduled Pinned Locked Moved QML and Qt Quick
10 Posts 4 Posters 4.8k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    aekam
    wrote on last edited by
    #1

    Hello,
    I am working on a project, in which UI part is written in QML and back end processing is done with C++.
    Now I was wondering that "how does the scene [or change in the scene] is reflected on screen".???
    exact flow right from the change in any property of any element in QML till it is reflected on display.

    The reason I am interested in this is that I wrote a code,

    @
    // main cpp file

    #include <QtDeclarative/QDeclarativeView>
    #include <QtGui/QApplication>

    int main(int argc, char *argv[])
    {
    QApplication app(argc, argv);
    QDeclarativeView view;

    view.setSource (QUrl::fromLocalFile &#40;"main.qml"&#41;);
    view.show();
    
    return app.exec();
    

    }
    @
    @
    // main qml file

    import QtQuick 1.0

    Item {
    width: 1920
    height: 1080
    property bool showBlue: false
    property bool showRed: false

    // first combination
    MouseArea {
        id: mouse1
        width: 200
        height: 100
        anchors.top: parent.top
        anchors.left: parent.left
        hoverEnabled: true
    
        onEntered: {
            showBlue = true
        }
    
        onExited: {
            showBlue = false
        }
    }
    
    Rectangle {
        id: rect1
        width: 200
        height: 100
        color: "blue"
        anchors.top: parent.top
        anchors.left: parent.left
        visible: showBlue
    }
    
    Rectangle {
        id: rect2
        width: 200
        height: 100
        color: "blue"
        anchors.bottom: parent.bottom
        anchors.right: parent.right
        visible: showBlue
    }
    //////////////////////////////
    
    // second combination
    MouseArea {
        id: mouse3
        width: 200
        height: 100
        anchors.bottom: parent.bottom
        anchors.left: parent.left
        hoverEnabled: true
    
        onEntered: {
            showRed = true
        }
    
        onExited: {
            showRed = false
        }
    }
    
    Rectangle {
        id: rect3
        width: 200
        height: 100
        color: "red"
        anchors.bottom: parent.bottom
        anchors.left: parent.left
        visible: showRed
    }
    //////////////////////////////
    

    }
    @

    I loaded this code in my board and it shows that for first MouseArea-Rectangle combination, mouse pointer gets stuck (main event loop gets blocked for some reason, maybe.??) while entering and exiting the mouse area.
    While for the second MouseArea-Rectangle combination, it doesn't.
    What could be the possible reasons.??

    If you need more information, let me know...

    If you take care of inches, you won't have to worry about miles... :)

    1 Reply Last reply
    0
    • sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #2

      See those 2 blogs from KDAB:

      • "QML part 1":http://www.kdab.com/qml-engine-internals-part-1-qml-file-loading
      • "QML part 2":http://www.kdab.com/qml-engine-internals-part-2-bindings

      (Z(:^

      1 Reply Last reply
      0
      • A Offline
        A Offline
        aekam
        wrote on last edited by
        #3

        Thank you... these posts gave me pretty good information about underlying layers of QML.
        I ran the program in my desktop with Qt Profiler, and it takes too less time in any operation and UI response is fine. But still I have problems regarding the performance in my board.

        One observation i made is that Qt offers an example "Testing the Linux Framebuffer". I ran it in desktop and in my board. the values i get is,

        for desktop
        Frame Buffer Performance test...
        Average: 2005 usecs
        Bandwidth: 2010.599 MByte/Sec
        Max. FPS: 498.753 fps

        for board
        Frame Buffer Performance test...
        Average: 26751 usecs
        Bandwidth: 295.696 MByte/Sec
        Max. FPS: 37.382 fps

        does this mean that my board is not fast enough to update the scene.??

        [EDIT]
        PS. my board doesn't have graphic accelerator...

        If you take care of inches, you won't have to worry about miles... :)

        1 Reply Last reply
        0
        • A Offline
          A Offline
          aekam
          wrote on last edited by
          #4

          one more question, does the stack of different UI elements [rectangles, images, mouse areas etc...] affects the performance.??

          If you take care of inches, you won't have to worry about miles... :)

          1 Reply Last reply
          0
          • sierdzioS Offline
            sierdzioS Offline
            sierdzio
            Moderators
            wrote on last edited by
            #5

            Well, definitely, the more stuff you pack into the scene, the more resources will it use.

            Also, traversing the QML hierarchy can be pricy. That is why it's best to shorten invocations. Example:
            @
            // orig - bad
            parent.child.kid.color = Qt.red;
            parent.child.kid.width = 500;
            parent.child.kid.height = 400;
            // better:
            var kid = parent.child.kid;
            kid.color = Qt.red;
            kid.width = 500;
            kid.height = 400;
            @

            (Z(:^

            1 Reply Last reply
            0
            • A Offline
              A Offline
              aekam
              wrote on last edited by
              #6

              Yes, I can understand that, but in the code I mentioned at the beginning of the post has nothing more than a MouseArea and two rectangles. The only processing I do in Mouse Enter/Exit events is to change the color of rectangles. Still the mouse gets stuck at boundery of the mouse area. So this is quite a bit confusing to understand.

              Not getting any clue...
              1] frame buffer size is 1920 x 1080, 24bit color system, [large buffer] can this be a problem.??? maybe the main event loop get block while updating the scene.
              2] The board doesn't use any graphics accelaretor. Is it getting slow because of this.???

              any hints.??

              If you take care of inches, you won't have to worry about miles... :)

              1 Reply Last reply
              0
              • sierdzioS Offline
                sierdzioS Offline
                sierdzio
                Moderators
                wrote on last edited by
                #7

                [quote author="aekam" date="1355140891"]
                2] The board doesn't use any graphics accelaretor. Is it getting slow because of this.???[/quote]

                QtQuick1 uses CPU only. QtQuick2 uses the GPU or CPU through mesa.

                (Z(:^

                1 Reply Last reply
                0
                • C Offline
                  C Offline
                  chrisadams
                  wrote on last edited by
                  #8

                  Preface this by saying that I'm not too familiar with the codepaths, so I might be wrong about this stuff. But my understanding (at a very general, overview level) is:

                  In QtQuick1, every item in the scene has its paint method called, and is responsible for painting itself. In QtQuick2, every item in the scene is responsible for telling the scenegraph when the associated geometry node is modified. Every dirty node has its paint method called every frame, basically, although there are differences depending on what precisely is being painted (eg, text vs images vs rectangles).

                  If you want more details, read Gunnar's series of blog posts (you'll have to search the archive at blog.qt.digia.com for those).

                  Cheers,
                  Chris.

                  1 Reply Last reply
                  0
                  • A Offline
                    A Offline
                    aekam
                    wrote on last edited by
                    #9

                    [quote author="chrisadams" date="1355194232"]
                    In QtQuick1, every item in the scene has its paint method called, and is responsible for painting itself. In QtQuick2, every item in the scene is responsible for telling the scenegraph when the associated geometry node is modified.[/quote]

                    Does this mean that in QtQuick 1.0 whenever there is change in property of multiple elements simulteneoiusly, each and every element calls its paint method individually and more over sequencially, one by one.???

                    If you take care of inches, you won't have to worry about miles... :)

                    1 Reply Last reply
                    0
                    • E Offline
                      E Offline
                      elpuri
                      wrote on last edited by
                      #10

                      [quote author="aekam" date="1355393909"]
                      Does this mean that in QtQuick 1.0 whenever there is change in property of multiple elements simulteneoiusly, each and every element calls its paint method individually and more over sequencially, one by one.???[/quote]

                      In QtQuick 1.0 all the visual elements are QGraphicsItems. Whenever you change a property that changes the visual appearance of an item the item usually calls QGraphicsItem::update on itself (see for example QDeclarativeRectangle::setColor()). This tells the graphics view framework that this item is dirty and should be repainted.

                      Which items' paint() functions then get called depends on the viewport update mode of your QGraphicsView/QDeclarativeView. Check out http://qt-project.org/doc/qt-4.8/qgraphicsview.html#ViewportUpdateMode-enum for description of the different modes. When you use QDeclarativeView, the default is BoundingRectViewportUpdate.

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved