Results 1 to 16 of 16

Thread: QGLWidget 2d painting performance

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jan 2008
    Posts
    11
    Qt products
    Qt4
    Platforms
    MacOS X Windows

    Default QGLWidget 2d painting performance

    Hi,

    I'm doing some experiments on using OpenGL with Qt. My app is a small image viewer, that allows for browsing images by pressing the cursor keys. For the transition from the overview to the single image view I'd like to realize a zooming animation in OpenGL.

    According to Trolltechs "Overpainting" example you can mix QPainter commands and OpenGL commands in one class (using paintEvent instead of paintGL). So I started to replace QWidget by QGLWidget, nothing more. Unfortunately the application reacts much slower (same paint method, no OpenGL commands yet). I took a bunch of images and pressed a cursor until I reached the end. The GLWidget took about 30 % more time. So my question is, if there is some kind of overhead that prevents QGLWidget from being as fast as a normal QWidget? I really like to mix OpenGL and normal drawing in one widget!

    By the way, this behavior is the same on several machines. And having a look at Trolltech's Overpainting example where they compare a QGLWidget and an QWidget that use the same paint method code, I have the impression that the QWidget variant runs smoother that that GL one.

    Regards,
    André

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QGLWidget 2d painting performance

    Do you have hardware accelerated OpenGL implementation installed? Overpainting is in general slower than plain OGL because it uses overlays as far as I understand it.

  3. #3
    Join Date
    Jan 2008
    Posts
    11
    Qt products
    Qt4
    Platforms
    MacOS X Windows

    Default Re: QGLWidget 2d painting performance

    I'm pretty sure I'm using the hardware accelerated version. The pro file contains the OpenGL flag and when I'm painting using OpenGL I get incredible frame rates.

    But in my test case I'm not using any OpenGL commands or overpainting at all, I simply replaced QWidget by QGLWidget in my header file. The paintevent method keeps being the same. Doing so it seems my event loop is much slower (I get less keystroke events per time), like there is some overhead by the QGLWidget.

    Regards,
    André

  4. #4
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QGLWidget 2d painting performance

    Does it happen in every case? Try the chip demo and see if GL based viewport is slower than the regular one.

  5. #5
    Join Date
    Jan 2006
    Location
    Ohio
    Posts
    332
    Thanks
    37
    Thanked 8 Times in 4 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: QGLWidget 2d painting performance

    Could the slowdown be occurring because the QGLWidget is making calls to functions such as paintGL( ) and even though there is no real code in there, it is making extra function calls, causing the slowdown you are seeing?

  6. #6
    Join Date
    Jan 2008
    Posts
    11
    Qt products
    Qt4
    Platforms
    MacOS X Windows

    Default Re: QGLWidget 2d painting performance

    This behavior can be reproduced (at least on my Mac, don't have any windows PC here at the moment).

    Finally, I did some time measurements within my paint method. And it's definitely drawPixmap that causes the slowdown. What's happening is that QGLWidget tries to cache the image on the first drawPixmap. Of course this takes long but all subsequent paintings are very fast. QWidget does not cache, so all paintings constantly take the same time.

    In my test case this means (for a large image), caching time is about 50 milliseconds and after its cached no time can be measured for painting. QWidget takes about 1-2 milliseconds for a drawPixmap command. So in my case doing not that much repaints of the same image this options works a lot better for me.

    My question, is there any way of disabling caching of QGLWidget so that it can also be used like a normal QWidget for 2D Painting?

    Regards,
    André

  7. #7
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QGLWidget 2d painting performance

    I think the texture has to be sent into the graphics card before it is rendered thus your choices here might be limited. I'm just guessing though...

  8. #8
    Join Date
    Jan 2008
    Posts
    11
    Qt products
    Qt4
    Platforms
    MacOS X Windows

    Default Re: QGLWidget 2d painting performance

    Hmm, QWidgets drawing method has to transfer the image data to the graphic card as well but achieves a constant (quite fast) speed. QGLWidget however takes significant more time for the first drawPixmap command which looks pretty much like a caching operation. Maybe their algorithm isn't the fastest one (bindTexture() seems to me very slow as well).

    So, is there no option to influence Qt caching behavior? Once there was a method called setOptimization in QPixmap but this one disappeared in recent versions of Qt.

    Regards,
    André

  9. #9
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QGLWidget 2d painting performance

    Quote Originally Posted by amnesiac View Post
    Hmm, QWidgets drawing method has to transfer the image data to the graphic card as well but achieves a constant (quite fast) speed.
    But it doesn't convert it to textures first.

    So, is there no option to influence Qt caching behavior? Once there was a method called setOptimization in QPixmap but this one disappeared in recent versions of Qt.
    I don't know. Does the chip demo using GLWidget as a viewport work slow as well? I know I asked it before but I didn't receive a clear answer.

  10. #10
    Join Date
    Jan 2008
    Posts
    11
    Qt products
    Qt4
    Platforms
    MacOS X Windows

    Default Re: QGLWidget 2d painting performance

    Quote Originally Posted by wysota View Post
    But it doesn't convert it to textures first.
    Ok, so drawPixmap in GL context has to make a texture conversion before painting and caching it?

    Quote Originally Posted by wysota View Post
    I don't know. Does the chip demo using GLWidget as a viewport work slow as well? I know I asked it before but I didn't receive a clear answer.
    Sorry, what chip demo do you mean? I didn't find it amongst the Qt examples.

    Regards,
    André

  11. #11
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QGLWidget 2d painting performance

    Quote Originally Posted by amnesiac View Post
    Ok, so drawPixmap in GL context has to make a texture conversion before painting and caching it?
    Yes, that I'm almost sure of.

    Sorry, what chip demo do you mean? I didn't find it amongst the Qt examples.
    Well... it's in the "demos" directory and it's called "chip"

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.