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

[Thomas Lübking]

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



board.h
<https://git.reviewboard.kde.org/r/117785/#comment39485>

    this is now superfluous, was only used for "interesting" way to cause an update ;-)



board.cpp
<https://git.reviewboard.kde.org/r/117785/#comment39486>

    this is done by ::tick() and should not be done here as it pot. causes an extra repaint



board.cpp
<https://git.reviewboard.kde.org/r/117785/#comment39487>

    voilà, after a wall finishes the background changes and the occluded part needs an update - we just update the entire scene once what is suboptimal, but really doesn't matter (since you're rarely finishing walls in comparism to actual repaints per second ;-)



gameobject.h
<https://git.reviewboard.kde.org/r/117785/#comment39488>

    oh, 66 -> 62
    given screens will likely cap this at 60Hz anyway... it doesn't have major performance impact, though



wall.h
<https://git.reviewboard.kde.org/r/117785/#comment39489>

    i felt like guarding against wall updates for no reason ;-)



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

    growing the wall dirtifies it



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

    here's 64px alignment to reduce reallocation



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

    maybe those sprites should be cached as well, no idea.



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

    building a wall dirtifies as well


- Thomas Lübking


On April 26, 2014, 1:17 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 26, 2014, 1:17 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 
>   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/20140426/32119143/attachment-0001.html>