×

Discussion Board

Results 1 to 10 of 10

Hybrid View

  1. #1
    Registered User
    Join Date
    Oct 2009
    Posts
    90

    Problem with QGraphicsView performance

    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:

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

    Code:
    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:

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

    Code:
    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!
    Last edited by jano_alex_es; 2011-02-06 at 10:52. Reason: update information

  2. #2
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Problem with QGraphicsView performance

    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.

  3. #3
    Registered User
    Join Date
    Oct 2009
    Posts
    90

    Re: Problem with QGraphicsView performance

    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?

  4. #4
    Regular Contributor
    Join Date
    Sep 2008
    Posts
    286

    Re: Problem with QGraphicsView performance

    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.

  5. #5
    Registered User
    Join Date
    Dec 2006
    Posts
    2,280

    Re: Problem with QGraphicsView performance

    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?

  6. #6
    Registered User
    Join Date
    Oct 2009
    Posts
    90

    Re: Problem with QGraphicsView performance

    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.

Similar Threads

  1. QGraphicsView
    By vlad2048 in forum Qt
    Replies: 6
    Last Post: 2010-11-13, 23:19
  2. Urgent!!! Problem with Carbide Performance Investigator
    By amu09 in forum Carbide.c++ IDE and plug-ins (Closed)
    Replies: 1
    Last Post: 2009-08-26, 09:20
  3. Replies: 4
    Last Post: 2007-11-26, 09:38
  4. Performance problem with Nokia Prototype SDK 4.0 emulators.
    By mikeaf in forum Mobile Java Tools & SDKs
    Replies: 7
    Last Post: 2006-08-04, 13:04

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×