I am using Qt3 (version 3) for my user input and QGLWidget to display a strip chart. I don’t know if this is a Qt question or openGL but it looks like openGL.
A couple of weeks ago, when my app was working I checked up on paintGL() and found that it was being called at 60 Hz. Nothing in my code called it so I surmised that it was being called automatically from either Qt or OpenGL, cannot determine which. Either way, cool, use that to keep my display updated.
While trying to make the display driven by time everything stopped. After much messing around I added code back in to check the call rate for paintGL() and its not getting called. As I verified that I was not calling it from anywhere, I don’t know what might have done to cause it to not be called. I am finding some things about paintGL and other things that might cause it to be called, but nothing about what causes it to be called automatically at a regular interval.
Have you any clues as to where/what I should look?
The paintGL() method is called from the default paintEvent() method, which is called from the event loop in response to paint events (aka expose or redraw events), as well as via repaint() (update() generates a paint event which will cause the paintEvent() handler to be called when it’s received; repaint() calls the handler immediately). It’s also called from updateGL(), which is available if the application wants to force an immediate redraw.
If paintGL() was being called constantly, it’s possible that the code which handles paint events was itself generating paint events.
[QUOTE=mbkelly;398127]I am using Qt3 (version 3) for my user input and QGLWidget … paintGL() … found that it was being called at 60 Hz.
…
Nothing in my code called it so I surmised that it was being called automatically from either Qt or OpenGL, cannot determine which. Either way, cool, use that to keep my display updated.
…
After much messing around I added code back in to check the call rate for paintGL() and its not getting called.
…
Have you any clues as to where/what I should look?[/QUOTE]
The problem is that its NOT being called. It was but is not. If I write code to call it in a regular basis, then something might change and it will be called again, twice as often is needed.
Is there some function I can use to tell openGL or Qt to resume/start calling it like it was in an earlier version?
You should not write your application such that it relies on Qt to call it at precise intervals. Instead, you should write your paintGL function to adapt to how much time has passed since the last paintGL call. You’ll still need to force it to be called at regular intervals if you need an animated scene, but you shouldn’t write code that assumes you will get a paintGL call at every X milliseconds.
Or you could switch to a platform like GLFW, where you get greater control over this sort of thing. Also, Qt 3 is old, last updated nearly fifteen years ago. So maybe you should switch to something more recent on general principle.
[QUOTE=mbkelly;398132]
Is there some function I can use to tell openGL or Qt to resume/start calling it like it was in an earlier version?[/QUOTE]
Call update() from paintGL(). That will append a paint event to the event queue. The next time that Qt processes the event queue, it will call paintEvent() and paintGL() again. Paint events are coalesced; it will only call paintEvent() once even if there are multiple paint events in the queue.
If a previous version was updating continuously and you don’t know why, it’s probably because the redraw code was implicitly generating paint events, either via update() or from Qt using an OS API function which implicitly generates a paint event.
Alfonse Reinheart:
I don’t care about precise intervals. Almost immediately after I started this project I read in the book to override resizeGL() and paintGL() and the later is called without any explicit code on my part. Then it stopped.
Yes, Qt3 is a major problem. I could explain in details but keeping it simple, the estimate is at least a man year to update and all the experienced people have moved on. And the government has changed their rules about using code that is foreign owned. They hate that. Qt has always been foreign owned, but the rules changed so we can keep what we have but cannot introduce the new stuff.
And again, yes, it is a royal PIA.
GClemets:
Ok, that update() suggestion looks good. Going to work that. I am adding a new widget just to show things like, how often paintGL() gets called, without continuously scrolling the command line. This runs under Centos Linux.
In the meantime: Does anyone know how to find the controls that govern when paintGL() is automatically called?
Is that an OpenGL function or a Qt function?
To repeat, this is a Qt app that includes widget QGLWidget which creates a strip chart embedded in the QT app. The Qt app manages all the user controls.
It’s a Qt function. If you want to know the precise details of when it’s called, search the Qt source code for paintGL() and follow the chain backwards. But for the most part, you’re going to end up with “it gets called in response to paint events” (under X11, that’s an event with a type of Expose or GraphicsExpose), and those can be generated by the X server (or even sent from other applications via the XSendEvent() function).
But in your case, the source was almost certainly your own application. Methods which change (or even might change) a widget’s contents typically call update() to ensure that the widget is redrawn. The update() method enqueues a paint event for the widget so that if there are multiple such changes in quick succession, the widget only gets redrawn once (this also ensures that calling update() in a paint hander doesn’t result in infinite recursion).