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

[Ian Wadham]

> 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?
> 
> Thomas Lübking wrote:
>     *blast*
>     valgrind with "--tool=callgrind", of course.
> 
> Ian Wadham wrote:
>     Maybe the difference is in the way CPU % is calculated. For me, on Apple OS X, it is % of one core. I won't be trying valgrind just yet. I am working on the bigger issue of how to get all KDE apps on Apple to use raster graphics at all times.
> 
> Thomas Lübking wrote:
>     I monitored the assigned core only.
>     Could however also be cpu overhead in apples compositor (ie. screen updates cause cou load? glxgears dows probably not count as testcase)

I tried another test, but with KGoldrunner (just the introductory demo levels, which are automated). It was using 10-15% CPU also, which IME is not unusual for animation based on Qt 2D graphics. I noticed, however, that an Apple OS X process called WindowServer was running at about the same or more CPU than KBounce or KGoldrunner. It would not surprise me if there is some interaction (and blocking) going on with Qt there. I have seen discussions in Apple forums about WindowServer slowdowns. It reminds me of what happened when we tried the pre-release of QGraphicsView with KGoldrunner circa 2007. QGV and X11 Server used to chew up equally large amounts of CPU time. If I can get a Linux dual-boot going sometime, I might try and see if I can get the CPU in Linux down to the 1-2% you experienced, Thomas.

Meanwhile, I think KBounce is going fast enough for now, so please do not worry about it much more, Thomas.

Roney, you are the KBounce maintainer. Please commit or say 'Ship it' for Thomas' patches if you wish.


- Ian


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


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/254b6cf8/attachment.html>