[Kde-games-devel] Review Request: New framework KGameRenderer (to be added to libkdegames)

[Stefan Majewsky]

> On 2010-07-14 22:39:42, Parker Coates wrote:
> > trunk/KDE/kdegames/libkdegames/kgamerendereditem.h, lines 57-68
> > <http://reviewboard.kde.org/r/4283/diff/6/?file=30035#file30035line57>
> >
> >     Could you give an explanation of what these methods are for? Having read the API docs and how they're used in KDiamond, I still don't get how the item size can be automatically determined by having a pointer to the QGV.

A normal QGraphicsPixmapItem has the bounding rect (0, 0, width, height), which requires one to move stuff around when the pixmap sizes change in a resize event.

If a primary view is set, the coordinate system is transformed such that the bounding rect is always (0, 0, 1, 1). The internal pixmap item uses the paint events to decide on its actual render size, but the logical size of the item (in item coordinates) is still 1x1. The primary view thus allows to decouple the rendering coordinates from the logical coordinates.

If you look at the kolf-refactoring branch of <http://git.bethselamin.de/?p=kdegames-work.git;a=summary>, you'll see a more interesting application of the primaryView property. Kolf uses a fixed 400x400 size for the course, yet is full of rescaling code that handles mapping to the view coordinates. This is no longer necessary when all relevant items are KGameRenderedItems which determine their render size automatically.


> On 2010-07-14 22:39:42, Parker Coates wrote:
> > trunk/KDE/kdegames/libkdegames/kgamerenderer.h, lines 153-164
> > <http://reviewboard.kde.org/r/4283/diff/6/?file=30037#file30037line153>
> >
> >     If the defaults are acceptable for 99% of games and we have less than 40 games, then do we really need to handle those corner cases for the 0.4 games that use them? :)
> >     
> >     Honestly, if a games graphic needs are such that these "optimisations" don't actually help then I see two likely cases: the games is so simple that it doesn't really care about the extra performance overhead or the game is so specialised that it will want it's own rendering stack. So unless there are other strategies planned that users will actually change the defaults on, I'd be in favour of pulling these methods out to keep the API simple and to remove a level of conditionals from the code.
> >     
> >

I'm actually thinking about disabling some of the optimisation strategies in Kolf. For example, it needs its pixmaps at so many different sizes that the cache is not particularly useful.


- Stefan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4283/#review6565
-----------------------------------------------------------


On 2010-07-03 13:43:36, Stefan Majewsky wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4283/
> -----------------------------------------------------------
> 
> (Updated 2010-07-03 13:43:36)
> 
> 
> Review request for KDE Games.
> 
> 
> Summary
> -------
> 
> KGameRenderer is a small SVG->pixmap rendering framework for use in KDE games. I want to add it to libkdegames in the 4.6 cycle. For the story behind it, see http://kde.markmail.org/message/plfkwfeoni6nvpk2
> 
> Most important features:
> - management of SVG themes (via KGameTheme and QSvgRenderer)
> - reading of animated sprites (i.e. multiple SVG elements which are displayed one after the other to obtain an animation)
> - multithreaded rendering
> - two caching levels (in-process QHashes and shared KSharedDataCache)
> - integration with QGraphicsView through the KGameRenderedItem class
> - integrability with any existing implementations through the KGameRendererClient base class
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdegames/libkdegames/CMakeLists.txt 1138526 
>   trunk/KDE/kdegames/libkdegames/includes/CMakeLists.txt 1138526 
>   trunk/KDE/kdegames/libkdegames/includes/KGameRenderedItem PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/includes/KGameRenderer PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/includes/KGameRendererClient PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerendereditem.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerendereditem.cpp PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerenderer.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerenderer.cpp PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerenderer_p.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerendererclient.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgamerendererclient.cpp PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/4283/diff
> 
> 
> Testing
> -------
> 
> As part of a general refactoring, I have ported KDiamond to KGameRenderer in a local Git working branch which is available from git://git.bethselamin.de/kdegames-work.git (branch "kgamerenderer"). The port is stable and much faster, both in animation performance and startup time. Also, memory usage is about 1 MB lower in both the cold-start and warm-start scenario (i.e., without and with disk caches).
> 
> 
> Thanks,
> 
> Stefan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20100715/e4dc0079/attachment-0001.htm