KGameCanvas is a small and lightweight canvas that i had written in Qt 4.0/4.1 times, when QGV was not yet available or still very buggy, because we needed a very simple canvas to use in KBoard (now Tagua), and we did not need complex optizations for handling milions of items that actually resulted in a noticeable slowdown in many games and game-like tests. Something very much like the canvas in Qt 3, even if i’d say probably somewhat better. That said, KGC would never deserve to exist in a perfect world, and even in our unperfect world looks like that QGV finally catched up what was missing and is now working very well in small games with many animated items, outperforming KGC because it can avoid clipping the painter (and this can be a quite expensive operation if the region is complex). A small test program writtem by Paolo Capriotti can be found in the git repository at http://repo.or.cz/w/kgcqgv.git, a flag in CMakeLists.txt can be set to chose between KGC and QGV, just run and click to add a new item.
I feel very happy that we are now ready to get rid of KGC, in the unix philosophy there should generally be only one tool to do one job, and that tool will do its job well (even if i’d say that Qt is not following this philosophy very much because they are reinventing the wheel in many places, but well, they are just doing their best for something that is being sold and this can sometimes be the best choice to avoid complex dependencies). And it will probably be nice using a few of QGV’s advanced features in Tagua, such as event handling, transformations, etc. The only thing that i may want to complain is that i’ll now have to do some work to port the exisiting code 😀
my KDExperiments 
I believe that if it were not for KGameCanvas we would have not triggered lots of thinking and experimentation about issues that existed in previous versions of QGV. You are correct that with version 4.3 most of these have been addressed, but several games (KGoldRunner, KMahjongg) would not have been ported to Qt4 if KGameCanvas did not exist 12 months ago.
So thanks for writing it, and contributing it to libkdegames. And before you put it to sleep, let us see if KGoldRunner specially survives a re-conversion to QGV, just to be on the safe side 🙂
Thanks for your comment Mauricio!
In facts, i don’t think that I did a bad thing writing it, and did it precisely to make work the old kboard code with Qt4.
And before putting it definitively to sleep, we will still have to see if Tagua survives the port too (and not only KGoldRunner) 🙂
Hi, I made some benchmarks with KGameCanvas and QGV (with all optimization flags and Qt4.3) and KGameCanvas demonstrates to be much more faster. I’m developing for Nokia n800 devices, and QGV suffers to animate few sprites in it (with 5 sprites fps goes down to 8) while KGameCanvas handles 50 sprites with 20-30 fps. I made a program like ‘expedite’ to test and it was faster than Evas! Running this test with 128 images (overlapping each other) on the device the result was: QGV (8 fps), Evas (36 fps), KGameCanvas (55 fps).
The only problem I’m facing is that KGameCanvas seems to flick more than QGV and the animations sometimes are not linear (small freezes).
Do you know if there is some way to reduce flicker, changing part of KGameCanvas code? I thought it could be the repaint method, but changing to update didn’t solve.
I would like to use KGameCanvas because its perfect for what I need due to its lightweight engine. QGV is not light enough to run on these kind of devices yet.
Consider that KGameCanvas is now deprecated, instead look for the correct settings for QGV to make it fast (correct cache, clip, etc).
Regards!
Hi Maurizio,
I’ve already made all possible optmizations in QGV. (Index, Render Mode, Clip…). It has the worst performance among all my choices, and it’s very bloat. And neither QGV or kgamecanvas has all support for what I need (Edje support), so I would have to change the internal code anyway. It would be better if this core engine was lightweight and easy to mantain, and Trolltech license is very restrictive.