On Monday 15 August 2011 03:02:07 Zhu Qi Chao wrote: > -----Original Message----- > 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. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Alan, Thanks for your advice. It works for my problem. > > I rewrite the game logic through C++ to prove that less javascript could > improve performance. But for my rewriting game logic, it seems that the > performance has not that a big improvement as I expected. Dynamically > creating new visual item from .qml component still the big bottleneck > for the whole program. > So the simple replacement for js through C++ doesn't have any effect for > the performance improvement. I am striked!
Hi Qichao, 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). Regards, Romain -- Romain Pokrzywka | [email protected] | Senior Qt Software Engineer & Trainer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
