QWidget::update() and paintGL() slot lost.

[Paradox]

wysota, I agree with you about paintGL(), but in my situation I'm not able to find another way.

Follows me:

I'm using OSG (OpenSceneGraph) which have to call a frame() method to generate a new frame at each time. This frame() must be called inside paintGL(): if I don't call the frame() inside paintGL() there are a lot of errors about openGL, shaders and graphics context.

So, I assume to have to call the frame() only inside the paintGL(). This is the main assumption and can be wrong but for now I have no other idea.

Now, if the 3D OSG scene is static there are no problems! The problems happens when the 3D OSG scene is dynamic and the reason is the next: if we modify the 3D OSG scene WHEN the frame() method running we probably receive a segmentation fault because we can't modify the OSG 3D tree when OSG designs it.

So, I need to implement a methodology to avoid this situation. So, when I have finished to modify the OSG 3D tree, I have to force the paintGL() method to call the frame() method and then return to modify the OSG 3D tree.
If I'm not able to understand when the frame() is finished (this means "when paintGL() is finished") I can't able to procede with 3D tree modifications. This is the reason for the semaphore inside paintGL().

Now, if you understand this situation, I think that the problem is inside the first assumption: we have to don't call the frame() inside paintGL() but I don't understand how.

This is a problem between QT and OSG and is diffult for me to find a solution.

Many thanks for any ideas.

Bye

[wysota]

wysota, I agree with you about paintGL(), but in my situation I'm not able to find another way.

You have to find another way

I'm using OSG (OpenSceneGraph) which have to call a frame() method to generate a new frame at each time. This frame() must be called inside paintGL(): if I don't call the frame() inside paintGL() there are a lot of errors about openGL, shaders and graphics context.

You have to be aware that not every call to paintGL() should result with a new frame being generated.

So, I assume to have to call the frame() only inside the paintGL().

No. You have to call frame() after you make sure the proper GL context is made current (e.g. by calling makeCurrent() on the context).

Now, if the 3D OSG scene is static there are no problems! The problems happens when the 3D OSG scene is dynamic and the reason is the next: if we modify the 3D OSG scene WHEN the frame() method running we probably receive a segmentation fault because we can't modify the OSG 3D tree when OSG designs it.

Unless you have some worker threads in your code this will never happen.

So, I need to implement a methodology to avoid this situation. So, when I have finished to modify the OSG 3D tree, I have to force the paintGL() method to call the frame() method and then return to modify the OSG 3D tree.
If I'm not able to understand when the frame() is finished (this means "when paintGL() is finished") I can't able to procede with 3D tree modifications. This is the reason for the semaphore inside paintGL().

In general I would render the OSG frame to an FBO and then render that FBO to the target device in Qt's paintGL() (or a regular paintEvent since you don't have to use a GL canvas anymore). This way you can separate the two without any problems (provided that your hardware supports FBOs -- every modern hardware does). Apart from that your OSG engine should only modify the graph when you tell it to and not when it feels like doing so thus you should have total control over what happens when without any mutexes.