Problem with QGraphicsView performance

[jano_alex_es]

Hello,

I have a QGraphicsScene (800X300, 96pp) and I'm having performance problems when I try to implement a background image in a QGraphisScene.

There are not so many items, about ten. But it's really slow. Actually, it's going slower and slower. When the application is running about half minute it takes abut two seconds to react.

My first approach was:

//scene_test is just 20KB
QGraphicsPixmapItem* pPixScene = addPixmap(QPixmap(":/Scenes/Scene1/scene_test"));
    pPixScene->setPos(-78, -113);
    pPixScene = 0;

Second approach:

QBrush brsh;
    brsh.setTexture(QPixmap(":/Scenes/Scene1/scene_test"));
    this->setBackgroundBrush(brsh);

This is even worse, and if I try "m_pView->setCacheMode(QGraphicsView::CacheBackground);" it's definitly impossible.

I think I've tried all the optimization possibilities... for instance:

    m_pView->setContextMenuPolicy(Qt::NoContextMenu);
    m_pView->setDragMode(QGraphicsView::NoDrag);
    m_pView->setOptimizationFlags(QGraphicsView::DontSavePainterState |
                                  QGraphicsView::DontAdjustForAntialiasing);
    m_pView->setViewportUpdateMode(QGraphicsView::NoViewportUpdate/*QGraphicsView::SmartViewportUpdate*/);
//The updates are called manually. As showed in the next piece of code

    m_pView->setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
    m_pView->setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);

I'm controlling the framerate with the next code. But it only fails when I add the background.

void CGameEngine::renderTimer()
{
	m_timer.start();

        renderElements();

//Control the updates manually
        m_pCurrentScene->update();

        qDebug() << m_timer.elapsed();
        int iElapsed = 40-m_timer.elapsed(); //20 == 50 fps
        if(iElapsed > 0){
		QTimer::singleShot(iElapsed, this, SLOT(renderTimer()));
            }
	else
	{
		qDebug() << "Performance ERROR: " << iElapsed << " ms!!!!!!!";
		renderTimer();	
	}
}

what I don't understand is why this happens, it takes 2 or 3msec to execute all the code of each frame. Why can it be appearing so slow when I add the background?
Any idea? thanks!

[danhicksbyron]

If it gets slower as it runs, you probably have a storage leak.

Graphics speed is dramatically affected by the need to draw and redraw backgrounds. Have not played with QGraphics stuff much, but with regular UI stuff I've seen things slow down when a screen gets too many layers on it, or when screens are stacked and the UI code isn't made aware that the individual screens are opaque and so the ones behind do not need to be redrawn each time.

[jano_alex_es]

If it gets slower as it runs, you probably have a storage leak.

What's exactly storage leak? if it's like "memory leak" all the items are created at startup and they should stay on the scene until the end.

Actually, with only three graphics item on the screen (the background is one of them) I'm having performance problems... weird.

I'm thinking about the possibility to implement something as OpenGL. I'm a bit lost about the OpenGL-Qt objets, do you how could I convert a scene-view-item in order to use the openGL graphical functions?

[jakoskin]

Hi, your code gets slower because you are doing recursive loop in the else clause and not allow system to respond.
This won't work on event driven system as you prevent system from responding thus starving it.
Blitting large background takes time. Depending on which Qt version and which hardware you are running this on it can be just be too much.

You can profile it and see for yourself that your application thread takes 100% of CPU time.

[Sorcery-ltd]

It'd certainly be better to set a zero length timer and let the event loop run than simply call the function again. Another alternative in a tight loop is to call QCoreApplication:rocessEvents().

NoViewportUpdate is probably a bad idea, unless you really to need to re-draw everything. The automatic updates all get bundled up together when the event loop runs anyway, so smart or minimal updates will probably improve performance since you won't have to redraw everything.

If your background isn't at all transparent you could set the WA_OpaquePaintEvent & WA_NoSystemBackground attributes, which would save you drawing the system background and then drawing over the top again every frame.

What device are you trying to run this on?

[jano_alex_es]

In the end the problem was the "update". The system decides to draw whenever he wants to, and the update just draws on the screen (forcing the phone to make all the graphical calculations again) again. Remove it improves the performance a lot.

I found this video too. Needed if you want to improve QGraphicsView performance

Hi, your code gets slower because you are doing recursive loop in the else clause and not allow system to respond.

Sorry I didn't explain it. The class is running "renderTimer" forever, it's desired behavior. I want to execute renderElements() once each 40 miliseconds. So, if elapsed time is longer than 40, just launch again the function asap.

The automatic updates all get bundled up together when the event loop runs anyway, so smart or minimal updates will probably improve performance since you won't have to redraw everything.

I'm focusing now on it.

I'm testing it in a ExpressMusic.

[jakoskin]

Sorry I didn't explain it. The class is running "renderTimer" forever, it's desired behavior. I want to execute renderElements() once each 40 miliseconds. So, if elapsed time is longer than 40, just launch again the function asap.

I know what render loop is, yours however is flawed in the else clause.

        if(iElapsed > 0){
		QTimer::singleShot(iElapsed, this, SLOT(renderTimer()));
            }

This is ok as it allows event loop to run.

	else
	{
		qDebug() << "Performance ERROR: " << iElapsed << " ms!!!!!!!";
		renderTimer();	
	}

This isn't as it doesn't. And will eventually crash to stack overflow.

[jano_alex_es]

But then, if a frame takes more than 40 msecs the program will be stopped.

Note the else is almost never launched. But I need to have that option covered, just in case. The app uses to call the function once each 40 msces, and it uses to need 3 msecs, so despite all the automatic Qt stuff it "rests" 37,

[Sorcery-ltd]

No, just set a zero length timer instead of calling the function recursively. Otherwise you can get into a state (possibly on some devices you haven't tested on, or when something else is going on in the background) where you always take more than 40ms and eventually get a stack overflow as jakoskin says.

[jano_alex_es]

Well, I'd like to apologize.

I don't know where I had my head but I tried to do so many things at the same time, and in my hurry I just forget how to read in english...

Right now I realized what were you talking about. Fortunatly it wasn't going to cause troubles because all that code only takes 2 or 3 msecs but anyway it's a HUGE mistake. And I'm very thankful.

Just to add I'll set the timer for 3 msecs, because I've seen problems in the device if the timer is set to zero. Basically, sometimes it doesn't work fine. It does if the mobile is plugged and you are executing from the PC, but somehow it fails sometimes (not really often) if you are executing the app from the phone.