KGameRenderer: Less is more
July 3, 2010
Last month, I wrote about KGameRenderer, the integrated rendering framework for 2D games which I’m creating for the 4.6 release* of kdegames. If you followed the relevant development mailing lists (kde-core-devel, kde-games-devel) lately, you know that the first version is mostly done and in the review phase.
The productive atmosphere here in Tampere was the right opportunity for some benchmarking. I already knew from my experience that KGameRenderer-enabled games are faster, both in startup time and animation performance, than their counterparts using their own possibly suboptimal rendering code.
There’s another question, though: Does a sophisticated, multi-layered image cache use more memory than the more primitive solution? The short answer: No, it uses less. The long answer: I have measured memory usage of the 4.5 KDiamond and the KGameRenderer-powered KDiamond in different scenarios (with cache, without cache etc.) and found that the KGameRenderer-powered version consistently uses ~1MB less memory. That may not sound much, but it’s already over 7%** of KDiamond’s non-shared memory.
To put these numbers into perspective for our fellow developers: The KGameRenderer port of KDiamond actually uses a more complex item graph on its graphics scene (because diamonds are KGameRenderedItems now, which consist of two items internally), so the lower memory consumption comes mostly from clever caching strategies (e.g. by automatically discarding pixmaps generated by intermediate resize events which occur very often during a KXmlGuiWindow initialization). Another optimization which I expected to show up in this measurement is the delayed SVG loading. In fact, KGameRenderer does not load the SVG file at all if the cache is current and contains all needed pixmaps. However, there is no measureable difference in the lower memory consumption in the cold (without disk cache) and the warm start (with disk cache). This could possibly be different for games with complex SVG themes.
All in all, assuming that I have time to port enough games*** to KGameRenderer, you can expect 4.6 to be the least resource-intensive release of the kdegames 4.x series.
* Yes, I’m not talking about the 4.5 release, that one is basically over for me (modulo maintenance fixes). I’m already deep inside the 4.6 cycle and have started merging my feature branches, with KGameRenderer merge into trunk coming next week, in order to get as much testing as possible before the release.
** The numbers have been measured with KSysGuard and xrestop, and are just there to give you an idea of the dimensions. You probably know that there is no absolutely reliable way to measure memory usage of an application.
*** At the moment, there are only ports of KDiamond and KSame.