I have a QDialog-inherited class and one of its sub-window is initialized on resizeEvent like this.
void OpenGLWindow::resizeEvent(QResizeEvent *event) {
QWindow::resizeEvent(event);
// initialize on first call
if (m_context == nullptr)
initOpenGL();
resizeGL(width(), height());
}
Because OpenGL init needs width and height information, and need to adapt window size change, this init code can't move other place.
I should open this dialog and initialize some OpenGL draw objects.
m_Dialog->show();
m_Dialog->init(init_paramter); //I have to create opengl buffers of draw objects here
But unfortunately, resizeEvent() is called after init method was invoked.
e.g. current execution order is as following.
my_dialog_open_function() {
m_Dialog->show();
m_Dialog->init(init_paramter);
}
void OpenGLWindow::resizeEvent(QResizeEvent * event)
As OpenGL system was not initialized by resizeEvent Handler, my m_Dialog->init invoke crashes.
How can I get this execution flow?
m_Dialog->show();
void OpenGLWindow::resizeEvent(QResizeEvent * event)
m_Dialog->init(init_paramter);
Where is the proper place I can invoke my init function safely?
As #pptaszni mentioned in his comment, initOpenGL() doesn't look like it needs size information. So first I would reconsider the design.
As for the question:
The resize event is scheduled after the show and delivered when GUI events are processed. That's after your function returns.
You can simply delay the call by posting some event, which then will be delivered after the resize event. The easiest way is to use a single shot timer:
m_Dialog->show();
// Call me in 1ms
QTimer::singleShot(1, [=]() {
m_Dialog->init(init_paramter);
});
Note the delay of 1ms. If you call it with 0, Qt will optimize and call the handler immediately, so no gain there.
Related
I'm trying to time an application to see how long it takes to load up some information, and paint a graph. My function loads up the data first, then draws the graph.
The timing is fairly simple, it calls an external function that gets msecs since some date.
The problem is even if I set t1 in the beginning and t2 right after I call the draw function, t2 will return before the QGraphicsView is actually updated. (I know, it makes sense why this should be asynchronous)
For instance when I load a large file, it will return with 700 msecs after I subtract the two values, but the actual rendering doesn't finish until a few seconds later.
I've looked all over the web and scoured the Qt documentation. I can find tons of information on updating widgets yourself, but nothing on any kind of signal or event that is fired off after rendering finishes.
Even the QGraphicsScene::changed signal appears to only be fired off when the scene changes underneath, not when rendering is done and the user can SEE the changes.
Any help on how to do this?
Does a signal or event exist for when a QGraphicsView or QWidget is done being painted or rendered?
As far as I know, it does not exist. (looked for something similar)
user can SEE the changes
As far as I know, Qt uses double buffering, so if painting is finished, it doesn't mean that user can see the changes.
Any help on how to do this?
If you want to know when painting has finished, then...
You can subclass QGraphicsScene and implement your own drawItems, drawBackground or drawForeground. This is NOT simple (because item painting algorithm is complicated), but you'll be able to tell when every item has finished painted.
You can fire/emit signals from within paintEvent (QWidget-based classes) or paint() (QGraphicsItem/QGraphicsObject-based classes). You'll need to use your own classes, obviously, and you'll have to subclass either QGraphicsView, or items you're drawing within view, or QGraphicsScene.
You could also create proxy QPainter class, and this way you'll be able to know what exactly is being paitned and when.
Having said that I suspect you're approaching your problem incorrectly.
If you're only trying to draw a graph, then there's no reason for you to know when painting is finished.
If painting is finished, it doesn't mean user can see the result.
Paint events might be called more than once.
Recommended approach:
Receive/read the data (you're drawing in your graph) from external source using threads or timer events (you'll need to read it in small chunks if you're using timer events, obviously), then update the graph from time to time, and let Qt handle repainting.
How exactly does this allow me to detect the amount of time it takes from when I choose to open a file to when all the data is loaded and the graph is drawn and is visible?
You can detect when paintEvent has finished painting by subclassing whatever widget you're using to paint Graph, overriding paintEvent and firing signal from within paintEvent, calling a subroutine or doing whatever you want.
There is no warranty that paintEvent will be called only once.
To measure how slow individual routine is and locate bottlenecks, use profilers. VerySleepy, AQTime, and so on.
Instead of measuring how long it takes to load AND display data, it will make much more sense to measure separately loading time and display time. This is a GUI application, not a game engine, so you do not control precisely when something is being drawn.
I have not testet it, but I think by subclassing QGraphicsScene and reimplementing the render method you can measure the render time.
#include <QGraphicsScene>
#include <QTime>
class MyGraphicsScene : public QGraphicsScene
{
Q_OBJECT
public:
void render ( QPainter * painter, const QRectF & target = QRectF(), const QRectF & source = QRectF(), Qt::AspectRatioMode aspectRatioMode = Qt::KeepAspectRatio ) {
QTime t;
t.start();
QGraphicsScene::render (painter, target, source, aspectRatioMode);
qDebug("render time %d msec", t.elapsed());
}
};
I have the following code:
paintGL()
{
if(mouse_was_clicked)
{
... do the color picking with openGL to identify a clicked element
... !!! now I need to call again paintGL() to switch the selected element from the
old one to the new one but I can't create a recursive cycle!
}
else
{
... normal code to draw the scene and the selected element in red ...
}
}
As the lines suggest, I need a way to call once more the paint event.. is there any way to accomplish this without creating a potential livelock? Something like deferring a new paint event?
If the control flow within your paintGL() is that simple, just make sure that the contens currently being in the else block are executed in every case:
void MyWidget::paintGL()
{
if(mouse_was_clicked)
{
... do the color picking with openGL to identify a clicked element
}
... normal code to draw the scene and the selected element in red ...
}
It's a bit hard to tell exactly what you're doing here.
If you're trying to setup a display widget (a color picker) when paintGL detects a mouse button has been clicked, you've mixed up your events. You should make a separate action for handling a mouseclick, which sets up flags/variables and triggers a repaint. IE, move the mouse-event handling out of the repaint callback.
I could easily have misunderstood your problem here, however... if so I apologize.
As a general rule, though, if you find yourself needing a recursive repaint in QT, you're probably working against, rather than with, the system.
I'm using libqglviewer for a project, I read input from a motion capture device through USB and display this as a human in the viewer. I draw the opengl things in the draw() method of the viewer, it works fine. However, when the motion controllers change, I actually get new position values and i draw these in the viewer, BUT i dont see this update until i click on the viewer screen. Is it possible to update the frames in the viewer by itself?
It looks like you just need to post an updateGL right after you get the new position values.
QGLWidget::updateGL()
void QGLWidget::updateGL () [virtual slot]
Updates the widget by calling glDraw().
For painting in 2D the function is called update.
Also, don't call it from inside your draw method (see updateGL in the libQGLViewer documentation).
This note comes from QWidget::paintEvent():
Note: Generally, you should refrain from calling update() or repaint() inside a paintEvent(). For example, calling update() or repaint() on children inside a paintevent() results in undefined behavior; the child may or may not get a paint event.
The same probably applies for QGLViewer.
You can also use repaint, but is isn't recommended (see QWidget::repaint()).
I have a main window which has both a glut UI in the top 10% of the screen, and the openGL world in the bottom 90% of the screen. Every time my cursor starts hovering over the GLUT portion, openGL rendering will freeze. It resumes only when the cursor exits the GLUT area.
This is because as long as the cursor is hovering over the GLUT area, presumably glutIdleFunc is never called because glut is not "idle", so openGL stuff is not rendered.
I already tried making a new unrelated thread that just calls the display code and/or glutPostRedisplay but I got a framerate of whopping 20 fps as opposed to the 100+ fps the normal way. I don't know exactly why. (In this test I also disabled glutIdleFunc so there is no idle func, just the separate thread calling the display)
Ways to get around this (other than "stop using glut" which I might do in the future but for now I would like a temporary solution)?
I know this is an old question, but I was having a similar issue and wanted to share how I solved it.
Basically, in your idle function, you should manually set the window to your normal window ID. Thanks to Joel Davis' HexPlanet code ( https://github.com/joeld42/hexplanet/ ) for demonstrating this:
void glut_Idle( void )
{
// According to the GLUT specification, the current window is
// undefined during an idle callback. So we need to explicitly change
// it if necessary
if ( glutGetWindow() != g_glutMainWin )
{
glutSetWindow(g_glutMainWin);
}
...
}
Create a callback for passive motion func:
void passiveMouseFunc(int,int){
glutPostRedisplay();
}
And register it using:
glutPassiveMotionFunc(passiveMouseFunc);
I've made a project with Qt and OpenGL.
In Qt paintGL() was repeatedly call I beleive, so I was able to change values outside of that function and call update() so that it would paint a new image.
I also believe that it called initializeGL() as soon as you start up the program.
Now my question is:
I want that same functionality in a different program. I do not need to draw any images, etc. I just was wondering if there was a way to make a function like paintGL() that keeps being called so the application never closes. I tried just using a while(true) loop that kept my program running, but the GUI was inactive because of the while loop.
Any tips, other than threading preferably.
Thanks.
The exact mechanism will depend on which GUI toolkit you are using. In general, your app needs to service the run loop constantly for events to be dispatched. That is why your app was unresponsive when you had it running in a while loop.
If you need something repainted constantly, the easiest way is to create a timer when your window is created, and then in the timer even handler or callback, you invalidate your window which forces a repaint. Your paint handler can then be called at the frequency of your timer, such as 25 times per second.