[Qt-qml] Using QML canvas from C++, like QGraphicsView

[alan.alpert at nokia.com]

> -----Original Message-----
> From: ext Ville M. Vainio [mailto:vivainio at gmail.com]
> Sent: Wednesday, January 19, 2011 8:51 PM
> To: Alpert Alan (Nokia-MS-Qt/Brisbane)
> Cc: qt-qml at qt.nokia.com
> Subject: Re: [Qt-qml] Using QML canvas from C++, like QGraphicsView
> 
> On Wed, Jan 19, 2011 at 1:08 AM, Alan Alpert <alan.alpert at nokia.com>
> wrote:
> 
> > It sounds like he should use a mix. You can have a QGraphicsScene
> that loads
> > QML files for the menus and other frills and yet has QGraphicsObjects
> > controlled from C++ as the main feature. And you can expose those
> 
> That would prevent the app from benefiting from future scene graph
> speedups. What I was rather thinking is manipulating
> QDeclarativeItem's. Would you see the performance hit coming from
> going through qml layer in that way to be a concern?

If you just create plain QML items with minimal bindings and manipulate their properties then the performance hit should be minimal. You can still get the QDeclarativeItem* to not have to go through the property system. 

This seems like an odd hybridization, because if I'm understanding you correctly the app wouldn't be writing any custom paint event, just moving around 'Image' sprites based on the game rules. This is simplistic enough that he should probably do most of it in QML declaratively (the animation and UI and stuff), because otherwise he's trying to implement our animation code without access to internals which would probably be slower. 

Perhaps I'm just dwelling on the mention of implementing the animation in C++. If this case is merely that you don't want to write any game logic in Javascript you can do the logic part in C++, setting the x/y of the Items, and have that animated with Behaviors. One way this could be done would be to create a custom QObject exposed to QML containing the game logic, and with properties that get set to the relevant entities in QML. By getting the QDeclarativeItem pointers, and thus setting x/y directly instead of through the property system, the performance hit compared to using straight GraphicsView will be insignificant (although the startup time might be slightly longer, that shouldn't be significantly longer either).

Just keep in mind that it might still seem slower, because the ease of QML will encourage you to do so much more with it ;) .

--
Alan Alpert