[Kde-games-devel] Moving the KGameRenderer framework to pseudo-kdereview

[Parker Coates]

On Sun, Jul 4, 2010 at 11:37, Stefan Majewsky wrote:
> On Sunday 04 July 2010 00:01:46 Parker Coates wrote:
>> Does that mean that KGameRenderedItem no longer has a setOffset()
>> method? I use that in Killbots.
>
> I'll add one.
>
>> I'm also concerned with the potential runtime cost of doubling the
>> number of items in the scene. Would you mind elaborating on why you
>> felt the need to switch to QGraphicsObject? My understanding was that
>> it was only a convenience class for handling the QObject::parent()
>> QGraphicsItem::parent() conflict and the Q_INTERFACE.
>
> There is no conflict between the parent() methods because it's
> QGraphicsItem::parentItem() for exactly this reason. (Also, the APIDOX
> suggests to use QGraphicsItem::setParentItem and NOT QObject::setParent to
> model QGraphicsObject hierarchies.)

Sorry, I realise that it's not an API conflict, I should have been
clearer. I just meant that if you manually derive from QObject and
QGraphicsItem, you're dealing with two parental hierarchy that can
sometime conflict if your not careful.

> Then QGraphicsObject provides the properties, change signals, quick casting. I
> could copy all of this into KGRI, but sharing the implementation is especially
> good for future-proofness. If, say, Qt 4.8 brings a new feature in
> QGraphicsObject which is desperately needed by us, then I have no chance to
> use it if KGRI is QObject/QGraphicsPixmapItem-derived. With the
> QGraphicsObject superclass, I can stuff anything I like into KGRI internally.

Fair enough.

> On the runtime cost: It should not be much. Graphics View is designed to
> handle thousands of items (see the "chip" demo which comes with Qt) without
> producing much overhead. Perhaps someone of the Qt devs reading k-d@ could
> coment on that?

I don't really think the chip demo is an entirely "fair" test. The
chips in question are well spread out so the BSP is very balanced.
There's also no movement, colliding items, or parenting. It's
impressive, yes, but not really indicative of what we see with our
games.

It's not actually the runtime performance that concerns me so much as
the clunkiness the nested items adds from the library user's
perspective. Iterating through QGraphicsScene::items() or
collidingItems() or itemsAt() now takes twice as long, and the user is
expected to know which items he is allowed to touch and which ones he
isn't. Calling itemAt() will likely return the "wrong" item and one
will have to check that and get the parent item. And so on.

Having thought about this, QGraphicsPixmapItem doesn't really do
anything that fancy (ignoring the masking shape stuff, but I'm not
sure anybody in KDEGames is using that as it's quite expensive and
only needed for very fine collision detection of irregular shapes).
Why not just implement paint() and boundingRect() directly in KGRI?

Parker