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

Parker Coates parker.coates at kdemail.net
Thu Jul 15 00:39:40 CEST 2010


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


More questions/comments.


trunk/KDE/kdegames/libkdegames/kgamerendereditem.h
<http://reviewboard.kde.org/r/4283/#comment6323>

    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.



trunk/KDE/kdegames/libkdegames/kgamerenderer.h
<http://reviewboard.kde.org/r/4283/#comment6322>

    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.
    
    



trunk/KDE/kdegames/libkdegames/kgamerenderer.cpp
<http://reviewboard.kde.org/r/4283/#comment6321>

    I think we have to check the modification time of the .desktop file as well. Technically, the theme file itself could have been modified to point to a different SVG file.


- Parker


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/20100714/450e31e1/attachment-0001.htm 


More information about the kde-games-devel mailing list