[Kde-games-devel] QGraphicsScene performance

[mauricio at tabuleiro.com]

> 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.

> 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
> this discussion a bit and found one remark particular true, saying that
> it is ridicoulous that we can run less graphics objects on our 4 GhZ
> computers
> than a C64 could... ;-)

Well, there are some optimizations possible in QGV, and Fela's code was
not using them. One is a scene optimization to disable the BSP tree, in
scene.cpp:

Scene::Scene()
{
    setSceneRect(0, 0, WIDTH, HEIGHT);
    setItemIndexMethod(NoIndex);
...

With this in place there is a modest gain, and it know takes 20 balls to
reach 100% cpu, instead of the 15-16 we had before.

There are also view optimizations that you can use (main.cpp):

View view(&scene);   
view.setOptimizationFlags(QGraphicsView::DontClipPainter|QGraphicsView::DontSavePainterState);

This gives another performance boost, allowing us to open more objects,
maybe 30-35. BUT the drawing of the balls is incorrect due to us disabling
the antialias expanded rect, so at the end it is not an optimization that
applies to this specific case.

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!

Regards,
Mauricio Piacentini






view.setOptimizationFlags(QGraphicsView::DontClipPainter|QGraphicsView::DontSavePainterState);