Dynamically create visible items in SameGame example through C++

[pigling]

Hi All,
I am trying to rewrite the game logic in SameGame example through C++ code. But I suck in createBlocks() function where I can create the components successfully but they can't display on the view.
Original funciton in samegame.js

function createBlock()
{
    if (component.status == Component.Ready)
    {
        var dynamicObject = component.createObject(gameCanvas);
        ...
}

My C++ function

void GameData::createBlock()
{
    component = new QDeclarativeComponent(parentView->engine(), QUrl::fromLocalFile(blockSrc));
    QDeclarativeContext* context = parentView->rootContext();
    if (component->status() == QDeclarativeComponent::Ready)
    {
        QObject* dynamicObject = component->create(context);
        ....
}

I only add some "objectName" property in the .qml files so that it can help me to find child item. Then almost everything left unmodified in whole QML files.

From qDebug() I can see that dynamicObject has been created well. But I can't see any blocks in the view. What's wrong? If the component can't be built on proper QDeclarativeContext, couldn't it be displayed well, just like old style QWidget and QGraphicsScene hierarchies?

BTW, I can see main view but nothing happens after "New Game" button clicked.
Thanks.

regards,
pigling

[pigling]

Seems many people view the post. But no one gives the answer.
Fortunately, I get help from Qt QML mail list. Thanks for Alan Alpert from Nokia Qt, the problem gets solved:

It is much like the old QGraphicsItem hierarchies, but the context part is different. This is because the context is used for the declarative bindings but is not an item in the item tree. So it looks like you've created an object in the correct context, but you haven't set its parent item yet. Without a parent item it will not be visible in the scene, just like with QGraphicsItem.

You'll have to cast it to a QDeclarativeItem*, and then call
setParentItem(gameCanvas) (where gameCanvas is the QDeclarativeItem corresponding to gameCanvas in the samegame example.

Now the game is running well but the performance is not that great as I expected. Then I get the advice from Romain Pokrzywka in Klarälvdalens Datakonsult.

Thinking that C++ is more efficient that Javascript is a common assumption, but as you found out it isn't necessarily true. The reason is that Javascript engines have become extremely efficient over the past years (check out the V8 engine from google), and most of them also implement JIT (Just-In-Time) compiling, meaning that after the initial load the javascript code will execute almost as fast as a machine compiled code like C. This is what QML's javascript engine uses, which explains your results.

If you're looking for bottlenecks, what we found out to be the number one bottleneck in most cases is the number property bindings, and excessive binding updates resulting in a "binding spaghetti effect".

QML makes it dangerously easy to create property bindings, especially when combined with state machines, and if you're not careful you can end up having one small property change triggering a re-evaluation of a huge amount of properties.
And those don't come for free, especially on embedded hardware, which can then significantly alter the performance in your application.

One of my colleagues is preparing a detailed article about that "binding spaghetti effect", we'll make sure to post it on this mailing list when it's published online. There's some pretty interesting findings in there.

That said, it is still good to try to avoid putting logic in javascript as much as possible, so as to keep a clear separation between QML for the UI part of your application and C++ for the logic part (unless you don't want any C++ at all in your app).

Hope these can help anyone catches the samiliar problem like me.