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

aekam

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...

sierdzio

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

aekam

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...

aekam

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

sierdzio

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;
@

aekam

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.??

sierdzio

[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.

chrisadams

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.

aekam

[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.???

elpuri

[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.