[Kde-games-devel] Canvas updates

mauricio at tabuleiro.com mauricio at tabuleiro.com
Wed Sep 27 12:04:39 CEST 2006


Maurizio Monge wrote:
> Hi, unluckily i never received the mail you are answering, where was it
sent?

I believe all messages in this thread can be found at kde-games-devel
archives : http://lists.kde.org/?l=kde-games-devel

The discussion started on the previous thread
Re: [Kde-games-devel] aKademy 2006 BoF session ideas

> For the bug, i'm quite sure that Pixmap::setPixmap will not update the
> entire group,

Well, it should not, but this is not what I am seeing when I run
KGoldrunner. I placed trace information in several places and confirmed
it. Just revert the last one line patch in KGoldRunner SVN, and run the
previous version with

export QT_FLUSH_PAINT=1

and you will see that it does mark all members of the background group as
m_changed when you setPixmap on only one. Did you try it?

> does your patch really improves performance?

Yes, just a bit, in this specific situation only. It was already good, but
avoiding the update of the 700 tiles that have not moved avoids spikes on
lower end machines or ones with older video subsystems, and makes it
optimal.

> And BTW, that patch breaks the case of a group being moved, because in this
> case all the items have to be updated.

Yes, I know. I mentioned this in the last email, probably a redesign on
the inline changed() implementation was more appropriate than my one line
fix. Or each class (Pixmap, TiledPixmap) should call
KGrGameCanvasItem::changed() directly. But the one line fix shows you the
difference in updates, with it only one item (the one that had the
setPixmap change) changedInternal() is called. Otherwise the group
changeInternal() is called, and it marks all items are changed.

> I you want to debug the canvas updates, i recommend you to set the
> DEBUG_CANVAS_PAINTS define in canvas.cpp to 1, so you will have some
> visual feedback (if you are somewhat masochist put also
> DEBUG_DONT_MERGE_UPDATES to 1, this way you will see independently all
> the operations that modify the canvas)

DEBUG_DONT_MERGE_UPDATES caused a crash in KGoldrunner when set (before
the patch), with a segmentation fault. It works if you queue the metacall
only, but this is similar to calling the slot:

#if DEBUG_DONT_MERGE_UPDATES
  //updateChanges(); << segmentation fault here
  //workd if you change it to
  QMetaObject::invokeMethod(this, "updateChanges", Qt::QueuedConnection);
#else //DEBUG_DONT_MERGE_UPDATES
  QTimer::singleShot( 0, this, SLOT(updateChanges()) );
#endif //DEBUG_DONT_MERGE_UPDATES

But of course, you will not see the individual updates any more :) But you
will see the app.

Anyway, you can see updates (global) by exporting the environment variable
I mentioned above, even in release builds. Very useful, try it!

> I also have a very small update in the kboard svn (in
> playground/kboard/src/canvas)
> that unifies the changedInternal  and changed functions (just a cleanup,
they do
> the same thing anyway).

Well, maybe this solves the inheritance issue that was causing the problem
in the first place. I will see if I can get it from SVN to compare, or I
will simply repatch the kgoldrunner version. Maybe this is why you were
not seeing this in KBoard, or maybe the usage pattern is a bit different.

Regards,
Mauricio Piacentini




More information about the kde-games-devel mailing list