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

Parker Coates parker.coates at kdemail.net
Wed Jul 14 21:00:27 CEST 2010


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



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

    Keeping a separate cache seems like a lot of effort just to avoid a single char* to QImage conversion (which should be pretty quick). Did this actually make any difference in performance?
    
    Even if it did, a better approach may just be to add a "bool insertImage(key, image, &pixmap)" or similar method. If KGR runs into this issue than it wouldn't be surprising if other advanced users will too.


- 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/32b88293/attachment-0001.htm 


More information about the kde-games-devel mailing list