Slow QPaintEvents

[ToddAtWSU]

I am writing a program on Solaris 9 in Qt 4.1.4. I have a QMainWindow that all it contains is a menubar, toolbar, and a QGLWidget. I had been having problems that after printing it would slow down its redraws. I have now discovered it slows down when any other window partially obscures the window. If I bring a terminal window to the front or a print dialog or anything on top of my QMainWindow, the redraws take > 1 minute where before ever obstructing the window redraws would take 3-5 seconds. I decided to capture the QPaintEvent inside my QGLWidget class and have discovered that not only does the execution of my updateGL take longer, but half the time is wasted trying to get down to the QGLWidget QPaintEvent. What would cause this major slowdown in redrawing? I don't understand how obstructing the window suddenly makes it draw slower. I have even tried ignoring the repaints for the obstructed views so the only redraws that occur would be when the entire QMainWindow was redrawn. Thanks for your help!!

[e8johan]

The slowdown is most likely due to the clipping that takes place to avoid drawing over the window that obstructs parts of your window. Perhaps you could try rendering your scene to a buffer QPixmap and then copy that pixmap onto the widget in your paintEvent. That would probably be quicker - but you will have to render a new pixmap every time the OpenGL scene changes.

[ToddAtWSU]

That is what I thought was occuring but is there a reason why it takes ~30 seconds to even reach my paintEvent? Does it do the clipping before filtering down to my QGLWidget? If so do I need to catch the paintEvent inside my QMainWindow? Will this be a GIANT slow down to render to a QPixmap first since I have to pan and zoom-in/out on my OpenGL scene? One problem I see is how would I render the scene onto a QPixmap and then copy the pixmap onto the widget? Can i redirect OpenGL calls to go onto a QPixmap instead of the QGLWidget itself inside the paintGL function? Thanks for your help and sorry about all the questions, this is something I have not thought about using before.

[wysota]

Why do you "capture" the paint event of the gl widget? Does "printing" mean "printing on a printer"? Maybe you're "registering" something which causes additional slowdowns every repaint? Try producing a minimal compilable example reproducing the problem - it might help you pin down the issue.

[ToddAtWSU]

Why do you "capture" the paint event of the gl widget?

I started capturing it to try and track down the problem. I was hoping to ignore paint calls when the window was partially covered in the background. Under normal use I would not capture the paint event but to try and debug my issue I thought I would try that.

Does "printing" mean "printing on a printer"?

Printing means I load up a printing dialog and then after the user clicks the "Print" button the image is sent to the printer and printed onto paper.'

Maybe you're "registering" something which causes additional slowdowns every repaint?

What do you mean by "registering" something?

Another thing I thought about was trying to capture a X11 event...mainly called VisibilityNotify and try to ignore calls when it was PartiallyObscured or FullyObscured. I would return TRUE when either of these issues arose from my QMainWindow subclass. I printed out the value of the type of message being sent and noticed I was never receiving any VisibilityNotify events. I looked into qapplication_x11.cpp and found a switch statement begining in line 2692 and found all the cases that none of them were for a VisibilityNotify event. All the XEvents I did receive however appeared in this switch such as Focus In/Out, Enter and Leave, Mapping events and Property events as well as others. I am wondering if Qt is ignoring all other XEvents that aren't one of the cases.

Another weird issue is a person came to help me work on this and they had their preferences set up to have the windows work with "Point in Window To Make Active" where I always had my windows set up by "Click in Window To Make Active". We noticed when this person would partially obscure the main window but then hover over the QMainWindow and try to pan the image inside the QMainWindow's QGLWidget that the image would pan as fast as it had initially. My friend could then click on the title bar of the QMainWindow to pop it back to the front of the screen and it would reload fairly fast and the actions all behaved normally without a slowdown. We switched the preferences to do "Click in the window to make it active" and my friend experienced the slowdown. Switching it back to "Point in window" allowed it to behave as I would expect it to anytime. This does not make any sense to me, but this is how it behaved. Does this help resolve the issue any more than what I already had? I do not know because, to me, how you make a window active should not alter how it handles redraws.

Thanks for all your help and please let me know if I can answer any additional questions as this is a huge flaw in the program that needs to be fixed and I am getting into things I have never looked into before. Thanks!!!