[Kde-games-devel] QGraphicsScene performance

[mauricio at tabuleiro.com]

Fresh updates diretly from Glasgow :)

>> Maybe you should consider sending your two examples to Trolltech. I
can't see why QGV needs to have such a bad performance, and if they
would optimized it all programs using it would immediately profit.
>
> That is one of the intentions of posting the code to a KDE list, so it
can
> be analyzed and used as reference. But we will also talk with the TT
guys
> here in Glasgow during this week to try to narrow it down a bit better,
and offer our help if desired. This is something that Maurizio and Paolo
had raised earlier today, and I think it can produce good results. If
only
> we can learn optimization techniques in QGV directly from the source,
which can help all the games that use it. But it is not like we have not
done this before, Andreas actually spent some time last year debugging
KGoldrunner with me in Dublin. But the QGV API has changed since that
time
> (from 4.0 to 4.3), and maybe in small part due to the issues we raised.

I spent a couple of hours with Andreas (from TT) today, looking at these
issues, showing him some sample code and some workarounds we had in the
games, like the paintEvent subclass trick we had in KWin4, while waiting
for Qt4.3. He also showed me lots of small test applications he had, and
explained some of the modifications that went in 4.3 to address some of
the previous issues we ran into. And there are indeed great news in it :)

>> Even if it is argued that QGV is more general and flexible it might be
possible to switch off some features in favor of speed. I have followed

Yes, different update algorithms and policies apply to different
applications, and previous versions of QGV pre-4.3 really did not perform
well in some cases. But there is one new addition in 4.3, the
QGraphicsView::setViewportUpdateMode() method. This is something that did
not existed before, and it is a way for applications with specific needs
like games to change the update algorithm, or even to disable it
completely and handle this directly in your code. So in the case of the
sample app made by Fela, we could now (in 4.3) use:

View view(&scene);
//comment this out if you want to use OpenGL to draw the view   
//view.setViewport(new QGLWidget);
view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate);
view.setOptimizationFlags(QGraphicsView::DontClipPainter|QGraphicsView::DontSavePainterState);

I also modified the sample code to use a QGraphicsRectItem, so it can be
more readily comapared to the KGameCanvas one. And there are big and great
news: if you overide the default update method and set it to the new
FullViewportUdate then it will behave more or less like the subclassed
version we had in KWin4 (which btw came from a tip from Maurizio Monge).
In the case of this particular test app, this means that we can now add
100 items instead of the 15-20 we had before, and cpu usage will stay at
around 20% instead of going though the roof!

Try it from

http://www.tabuleiro.com/mauricio/balltest2.tgz

> So FOR THIS SPECIFIC CASE it is difficult to argue that KGameCanvas may
>have advantages due to its lightness. But as we saw this has to be
analyzed >in a case-by-case scenario, at least until we find the magical
key to >unlock all of QGV's performance in some of our games!

Well, with the new update flags in QGV 4.3 the result is actually
reversed, and QGV is using LESS cpu than KGameCanvas for 100 items. This
is probably due to both sets of new optimization flags: there are the
update ones I just mentioned, that solve the previous issue we had when
several smaller areas were being updated (in X11). But there are
additional ones, like the Painter flags in the code above that avoid
saving of QPainter state between items if your items do not need this, and
boost performance an additional 15-20% in this app, as I mentioned in my
previous email.

I encourage you guys that have QGV-based games to have a look at these new
flags, and see how they can improve the performance greatly. There are
also other update mode enumeration types, and maybe you can examine which
one is better for the particular needs of your game.

I also invited Andreas again to join us at the list and IRC channels, as
he is interested in finding out more about the performance bottlenecks
that we find in the future and how QGV can be made even more adequate for
our needs. He also has some game-like test apps that could maybe found a
way into a KDE game later, as we do not have any driving game yet :)

To me at least it is clear that the work we have been doing since QGV was
released has already helped TT identify some possible bottlenecks in the
code that existed in previous versions, and I am very happy to see that
these were considered and addressed in QGV 4.3, even if they are sometimes
not the default methods. Among the things that Andreas said he was
considered working on, one is particularly interesting for us: better
support for partial invalidation of the background cache, specially to
support the need of game authors like in the case of KGoldrunner, where we
want to invalidate only some tiles, and not the full background, and still
be able to use the tiles. So it appears things will only get better with
4.4 and on.

aKademy is already paying off for us, guys :) Now let us all experiment
with this new options to see how they work in each case.

Regards,
Mauricio Piacentini