GillesDebunne / libQGLViewer

libQGLViewer is an open source C++ library based on Qt that eases the creation of OpenGL 3D viewers.
Other
241 stars 94 forks source link

setBackgroundColor() don't work anymore in 2.7.0 #38

Closed kerautret closed 4 years ago

kerautret commented 7 years ago

On the current version the setBackgroundColor() don't work anymore when used for instance in a classic keyPressEvent() function. It seems to be related to the QOpenGLWidget change of version 2.7.0 since it was working on commit 8eb15ceaae61182f911bec34e47236902a2e3ab2 (ping @mgian ;) )

GillesDebunne commented 7 years ago

Indeed this code was changed in 2.7.0

The call to qglClearColor (QGLWidget only) was replaced by a call to:

glClearColor(color.redF(), color.greenF(), color.blueF(), color.alphaF());

which should be identical.

Can you make sure the color you provide is what you expect, especially its alpha value ?

Also make sure you do not call this method somewhere else with a different value.

Since this is called in keyPressEvent, make sure to call update() after (and not updateGL()) to force a repaint.

Or try to call this method directly at the beginning of your draw() method and see if it helps.

kerautret commented 7 years ago

Thanks for your fast reply 👍 I try to add alpha value which was missing but no change. Yes I also change the updateGL but ni effect. Finally I try your suggestion by calling it directly in the draw method and that works. ;) Perhaps add the precision in the doc ?

GillesDebunne commented 7 years ago

The alpha value is set to 255 by default in the QColor ctor. Since the code you shared uses this construction, it's normal that adding 255 has no effect.

I'm also surprised your calls to updateGL did not raise a compilation error. I get

use of undeclared identifier 'updateGL'; did you mean 'update'?

when I call this method in a 2.7.0 example.

And finally, I tried calling setBackgroundColor in init (and not draw) and it worked (in the simpleViewerexample).

I'm not entirely sure you are effectively using the 2.7.0 version, could you double check?

Closing for now since I cannot reproduce. Feel free to re-open if needed.

kerautret commented 7 years ago

Sure for the version, I no more use updateGL() that was the corrections to be use with 2.7.0 ... I also see that the setBackgroundColor works in the init() but the idea was to allow the user to change the background by using a special key during the visualisation. I will check again the version, thanks.

kerautret commented 7 years ago

I just tested using the simpleViewer of the example directory and the setBackgroundColor() has no effect in keyPressEvent() even after calling update().

kerautret commented 7 years ago

I cannot re open the issue since I have no right I think ;)

GillesDebunne commented 7 years ago

So it works when setBackgroundColor() is called in init(), but not when it's called later, like in a keyPressEvent, is that correct?

kerautret commented 7 years ago

exactly

mgian commented 7 years ago

As far as I understand, it seems to be a refresh/repaint problem. @kerautret Check the simpleViewer example at the setBkColor branch in my fork, it seems that it is doing what you are looking for. Basically in the keyPressEvent I set the background color using a member of the class, then call the repaint() method and then the update() method, while in the draw() method I call the setBackgroundColor() method to set the color. (the code should be simple enough)

I am not sure about putting the repaint() method directly into the setBackgroundcolor() call, anyway

kerautret commented 7 years ago

@mgian yes thanks, that was the equivalent patch that I apply on my project. If it is difficult to recover previous behavior perhaps it should be mentioned in the doc ?

mgian commented 7 years ago

As I suppose, putting the repaint() call in the setBackgroundColor() method end in a segmentation fault when the setBackgroundColor is called by the draw() method (as soon as the first call), otherwhise it seems to have no effect. So, to recover the previous behavior seems to difficult to me, but I don't know all the internals of both QOpenGLWiget and libQGLviewer. Maybe @GillesDebunne has a simple answer.