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

[Thomas Lübking]

> On April 27, 2014, 6:21 a.m., Ian Wadham wrote:
> > With your patch and with raster graphics only configured in the Qt installation, performance on Apple OS X was still slow. About 60% CPU for 2 balls on Easy level (but not 100% :-)). With -graphicssystem raster on the command-line, performance was good and CPU went down to about 15%. My CPU is Intel i7 quad-core at 2Ghz. I think the QTimer cycle time could be increased to about 30 msec without loss of animation quality.
> 
> Thomas Lübking wrote:
>     "33" - does that improve things further for you?
>     The QTimer could be replaced by an object timer and direct eventprocessing (rather than slot invocation - it's a minor overhead only, though)
>     
>     15% imo seem still far too much on that cpu - could you valgrind it?

*blast*
valgrind with "--tool=callgrind", of course.


- Thomas


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


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/20140427/1776cad2/attachment.html>