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

[Parker Coates]

On Mon, Jul 5, 2010 at 16:08, Stefan Majewsky wrote:
> On Monday 05 July 2010 16:50:13 Parker Coates wrote:
>> 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.
>
> Agreed, though I do not see how this is relevant to the discussion.

It isn't. :) I just wanted to clarify.

>> 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.
>
> Agreed again. I did not look from this perspective even though I suffered from
> these problems in the port of Kolf which I'm doing in my Git repo besides
> other things.
>
> I have solved this problem now with a fancy trick: I call the
> QGraphicsPixmapItem implementations of the subitem from the corresponding
> functions of the KGameRenderedItem, and reimplement empty the functions for
> the subitem. This way, I can reuse the QGraphicsPixmapItem reimplementation,
> but itemsAt() and friends will only see one item.

This means that items() will still list the private children though,
right? Maybe it isn't that big a deal, but there are currently 89
calls to QGraphicsScene::items() in KDEGames. I haven't bothered to
check what all those calls are actually doing, but obviously doubling
the length of the result will have some cost.

Also is KGameRenderedItem able to survive having it's child
deleted/moved/transformed? I'm still nervous about having private,
internal members visible from public API.

>> 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).
>
> The fine collision detection is an important detail which I do not want to
> miss in KDiamond, esp. for irregularly shaped diamonds. It was therefore out
> of question for me from the beginning to scrap the QGraphicsPixmapItem
> implementation completely.

Fair enough. That does raise the question of how users who would like
to use a different shape or transformation mode are supposed to do so.
This is very similar to my earlier request for the setOffset method.
Are we eventually going to have to make the entire QGraphicsPixmapItem
API public via pass-through methods? (Have you considered the trying
to inherit from <cringe>both</cringe> QGraphicsObject and
QGraphicsPixmapItem?)

Also, have you considered caching/sharing shapes? For a game like
KDiamond which has lots of items with identical pixmaps, computing the
shape once and sharing it among those items might be very beneficial.

Parker