<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/117785/">https://git.reviewboard.kde.org/r/117785/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 27th, 2014, 6:21 a.m. UTC, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On April 27th, 2014, 8:16 a.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">"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?</pre>
</blockquote>
<p>On April 27th, 2014, 8:17 a.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">*blast*
valgrind with "--tool=callgrind", of course.</pre>
</blockquote>
<p>On April 28th, 2014, 12:26 a.m. UTC, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On April 29th, 2014, 8:45 a.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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)</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
<br />
<p>- Ian</p>
<br />
<p>On April 28th, 2014, 7:35 p.m. UTC, Thomas Lübking wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDE Games, Ian Wadham and Roney Gomes.</div>
<div>By Thomas Lübking.</div>
<p style="color: grey;"><i>Updated April 28, 2014, 7:35 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kbounce
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">100% cpu -> 1-2% cpu and more fluid =)
No visible regression spotted.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>board.h <span style="color: grey">(75f66d4)</span></li>
<li>board.cpp <span style="color: grey">(46b923b)</span></li>
<li>gameobject.h <span style="color: grey">(9fb5788)</span></li>
<li>gamewidget.cpp <span style="color: grey">(23cb6ba)</span></li>
<li>wall.h <span style="color: grey">(c56efa1)</span></li>
<li>wall.cpp <span style="color: grey">(df487a0)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/117785/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>