[Kde-games-devel] Review Request 117785: fix performance issues

[Roney Gomes]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117785/#review57064
-----------------------------------------------------------


I ask you favor, stop doing unnecessary changes to the project's coding style. Although I also don't like it, those changes make your patch more difficult to read.

Consider carefully the issues I pointed bellow. If you have any questions or objections, feel free to expose them.

PS: for some reason I do not understand, the following glitches appeared when I tested your patch. See the screenshot: http://imagebin.org/308512


wall.cpp
<https://git.reviewboard.kde.org/r/117785/#comment39764>

    Why these variables need to be static? If they have to be preserved for future calls of update() then store them as private attributes of KBounceWall. Let's try to keep our code as object-oriented as possible.
    
    Notice that the same argument applies to gs_cachedSize.



wall.cpp
<https://git.reviewboard.kde.org/r/117785/#comment39765>

    This whole block does not belong here. What you're doing is fetching the sprites from the renderer only if the current tile size differs from the size you cached, that is, we have a resize.
    
    However, we already have a method for handling resize events. That's where this block should be placed in.
    
    The solution I propose:
    
    1. Make wallEndLeft, wallEndUp etc. private attributes of KBounceWall.
    
    2. Turn this block into a new method (fetchSprites() or render(), perhaps) and make a call to it inside KBounceWall::resize(). This way we're making our code more modular and easier to understand.
    
    3. To invalidate the cache when the user select a new theme you don't need to erase gs_cachedSize as is done currently, just call the new fetchSprites() method instead. Actually gs_cachedSize becomes completely unnecessary.
    


- Roney Gomes


On April 28, 2014, 7:35 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117785/
> -----------------------------------------------------------
> 
> (Updated April 28, 2014, 7:35 p.m.)
> 
> 
> Review request for KDE Games, Ian Wadham and Roney Gomes.
> 
> 
> Repository: kbounce
> 
> 
> Description
> -------
> 
> Roney, I hope your the correct addressee - Ian referecend some "Roney" in a private mail.
> The patch looks bigger than it is, i had to partially fix coding style in order to read through it, sorry.
> 
> The MAJOR issue with the code is that it causes recursions on the eventloop by altering graphicsitems from the paint() call ("setPixmap()"), so i scrathced that.
> It seems a cause was that a full repaint was forced by setting some invisible fullsize pixmap item, while the only requirement for this was actually when finishing a wall - so i replaced that with an explicit full update call on occasion.
> 
> Also all non-raster graphicssystems HATE QPixmap::fill(Qt::transparent) causing a 24bit -> 32bit change and it's esp. bad on the nvidia driver.
> So i reduced that (and allocation) by re-using the old (ARGB) pixmap on a 64x64 alignment.
> Ian, you might esp. check that impact on OSX.
> 
> Last I cached the sprites, seemed reducing cpu on permanent paint (but i didn't really measure)
> 
> I'll also mark & comment the actual changes in the diff.
> 
> 
> Diffs
> -----
> 
>   board.h 75f66d4 
>   board.cpp 46b923b 
>   gameobject.h 9fb5788 
>   gamewidget.cpp 23cb6ba 
>   wall.h c56efa1 
>   wall.cpp df487a0 
> 
> Diff: https://git.reviewboard.kde.org/r/117785/diff/
> 
> 
> Testing
> -------
> 
> 100% cpu -> 1-2% cpu and more fluid =)
> No visible regression spotted.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20140501/b00d55c7/attachment.html>