You should not call GUI function from a different thread. Signal and slots is the way to go.

@SGaist Alright, I'll give that a try. Thanks very much!

@thehans said in QOpenGLWidget::grabFrameBuffer() always ignores alpha channel?: Unfortunately I'm on Ubuntu 18.04 which is still on 5.9.5. Is there any chance of this fix being backported to earlier versions? Qt 5.9 is now in "very strict" update mode, which means in only receives security fixes. It no longer receives bug fixes. Your options are: Download and use Qt 5.12 or newer from https://www.qt.io/download-open-source, OR Apply the patch to your copy of Qt 5.9 and build it from source. I think the first option is easier.

Alright after developing spine problems from leaning into my screen for a week and losing more hair than my GPU has cores, I sort of fixed the issue. So for some reason when I was reading data into my textures without setting the active texture back to the GL_TEXTURE0 default, things were going sideways. So basically I had something like: glActiveTexture(GL_TEXTURE0 + inputTextureUnit[vid]); glBindTexture(GL_TEXTURE_2D, inputTextureID[vid]); glTexImage2D(GL_TEXTURE_2D, 0, GL_internalFormat[vid], videoSpecs[vid].videoWidth, videoSpecs[vid].videoHeight, 0, GL_format[vid], GL_UNSIGNED_BYTE, (const void*)(frame)); But this was missing at the end: glBindTexture(GL_TEXTURE_2D, 0); glActiveTexture(GL_TEXTURE0); But I'm not 100% convinced that this is the cause because if I read still images, there is no issue. Its only when I read videos that I see the flickering and black texture issue. It seems like when other widgets start rendering and there is a texture active, they somehow corrupt it but I would certainly appreciate it if anyone has input on what actually might be happening.

@BoboFuego said in How to use anti-aliasing on QGLWidget?: how can I add MyWidget.h as promoted class for it in the MainWindow constructor? Promoted class won't allow you to pass parameters to a constructor. Just don't add it in the designer at all. Lets say you've got this designer_widget as a central widget of the mian window in the designer. Just delete it entirely and add it in code: MainWindow::Mainwindow(QWidget* parent) : QMainWindow(parent) { ui->setupUi(this); MyWidget* gl_widget = new MyWidget(); setCentralWidget(gl_widget); }

Good ! Then please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has worked :)

Hi and welcome to devnet, From the looks of it you are using both glu and the fixed pipeline. Since you are starting a new project, may a suggest taking a look at the Qt OpenGL examples and their use of current technologies like shaders ?

Hi, You should add: Which version of Qt you were using before Which version of Qt you are using now Graphics card + driver Platform you are running on

What kind of data are these ?

Ok solved It appears that a GLOBAL surface setInterval overrides the setIntervals I did on my glWidget. Kinda weird that the global one overrides local one if local one was specified, is this a bug ? format.setSwapInterval(0); QSurfaceFormat::setDefaultFormat(format); overrides on widget > QSurfaceFormat format; format.setSwapInterval(0); setFormat(format);

Hey Thanks so much for your help! I spend a while longer on the topic, learning more about the buffer&widgetGL and now blit texture. I got as far as this project > https://sourceforge.net/projects/opengl-blit/files/ But I cant figure out why the blit does not work. I can see that the frameObject has proper texture/render. But when I try to blit it I got nothing. Any help would be great! TIA.

Using the minimal example above, I fixed this by removing this call in our QOpenGlWidget subclass's constructor: setAttribute( Qt::WA_PaintOnScreen, true ); Removing this got rid of the paintengine calls (and numerous other problems). Thanks!!!!

@SGaist Thank you so much! Your response was much helpful!

@dalishi You should not mix painter and gl calls like that. You should put gl calls between calls to beginNativePainting() and endNativePainting(), which are painter functions. It might also help to save the painter state before and restore it after depending on how it messes up your gl stuff. the docs here tell you what the painter does to the states.

Hi, Glad you found out and thanks for sharing ! What version of Qt are you using ? On which platform ? Did you check the bug report system to see if it's something known ?

I worked it out. It was because the QOpenGLWidget uses an FBO under the hood, and so all calls get redirected to it. I guess Qt doesn't then do any special mapping of FBO color attachments to display buffers to allow for GL_BACK_LEFT and friends to continue working seamlessly. Solution was to use a QOpenGLWindow instead, and I'm hoping that QWidget::createWindowContainer() will let me continue to work as expected.

Hi and welcome to devnet, Did you try with QStackedLayout with StackingMode set to StackAll ? Hope it helps

@kickoune103 said in error after start example qt5.8 for raspberrypi: -v it's use before. Then please post the actual configure output (at least the part where fontconfig is being tested).

@Devopia53 I tested on Qt 5.8/Win7 today. The same incorrect result. But today i discovered the difference in overlaping behavior on my two machines. On the machine with video card fully-transparent widget has black color on white opengl context :D, where as other machine with integrated video card has no color(as should). So the gui transparency on opengl context is very platform dependent. Solution is to render widget by opengl directly but this way is very inconvenient. I think troll-tech must solve this problem in future.

@NRUB I was just expecting that QObject will be destroyed while QApplication is finished Why? Qt doesn't track all objects, it guarantees only that the parent will delete the child, nothing more. So if you don't give a QObject a parent it'll just float out there and no one will delete it automatically, thus it will leak. is it possible to use QApplication instance as a parent for QObjects It is, because QCoreApplication (and consequently all its derived classes) is already a QObject. That's one of the reasons it's also sometimes referred to as the "root QObject". when my QWidget has no parent then it is alive as long as app is working and it is managed and deleted by app. You can't give a QWidget instance a QObject parent, but you can connect the QCoreApplication::aboutToQuit() signal to the QObject::deleteLater() slot and this'd solve your leakage problems. For example: int main(int argc, char ** argv) { QApplication app(argc, argv); QWidget * window = new QWidget(); QObject::connect(&app, &QCoreApplication::aboutToQuit, window, &QObject::deleteLater); window->show(); return QApplication::exec(); } OS is removing leftovers when app is finishing Which means that claimed memory will be released by the OS, but here the problem is that you actually need to have the heap allocated objects' destructors invoked, which the OS will not do. which as we know works like a bridge between real addressing space and page addressing space which is translated by OS Yes, we know that, but there are two issues with this. Firstly, there may not be any difference between physical and logical addressing and this is common when the OS is ran without paging; like I run my Linux without a swap partition. And secondly, paging has next to nothing in common with the problem here. in practice memory is not leaking when apps are destroyed Even if this were true, which it is for most OS-es, not taking care to clean up your resources leads to all kinds of funky stuff. For the most simple and obvious of examples - a driver holding a global resource is not deinitialized, and the global resource is left locked for the next program wanting to use it. Then what, should we restart the whole system? Just leaving the OS to clean up, especially in such obvious circumstances, is in my opinion a lazy approach to programming that does more harm than good in the long run. Not only don't a bit of discipline and a handful of good practices hurt, on the contrary, they will spare you the trouble of digging through deep stack traces unnecessarily ... Kind regards.

@saket I think the driver of your graphics card isn't able to understand the GLSL command. As i see you're using an Intel Graphics Card, i had a lot of problems with my GLSL code on several machines with Intel Graphics. Try to change the attributes and varying qualifiers: static const char *vertexShaderSource = "#version 140\n" "in vec4 posAttr;\n" "in vec4 colAttr;\n" "out vec4 col;\n" "uniform mat4 matrix;\n" "void main() {\n" " col = vec4(1, 0, 0, 1);\n" " gl_Position = matrix * posAttr;\n" "}\n"; static const char *fragmentShaderSource = "#version 140\n" "in vec4 col;\n" "out vec4 fragcol;\n" "void main() {\n" " //gl_FragColor = col;\n" " fragcol = col;\n" "}\n"; And try to get the Info from the shader after compilation (https://www.opengl.org/wiki/Shader_Compilation#Shader_error_handling) GLuint shader = glCreateShader(...); // Get strings for glShaderSource. glShaderSource(shader, ...); glCompileShader(shader); GLint isCompiled = 0; glGetShaderiv(shader, GL_COMPILE_STATUS, &isCompiled); if(isCompiled == GL_FALSE) { GLint maxLength = 0; glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &maxLength); // The maxLength includes the NULL character std::vector<GLchar> errorLog(maxLength); glGetShaderInfoLog(shader, maxLength, &maxLength, &errorLog[0]); // Provide the infolog in whatever manor you deem best. // Exit with failure. glDeleteShader(shader); // Don't leak the shader. return; } // Shader compilation is successful.

Hi, What kind of camera are you going to connect to ? Are they already supported by GStreamer ?

You'll need to change the context to the second GL widgets before using it. As each time you render or do anything with OpenGL setup/parameters that you have the right context selected first for each widget.

Hi, It's a little bit more complex than that. See this article about the various transformation that you can apply.

@jsulm There're no calls to paintEvent() or update() inside updateGL() void OpenGLWidget::updateGL() { makeCurrent(); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glEnable(GL_DEPTH_TEST); glDepthFunc(GL_LEQUAL); //LEQUAL glEnable(GL_CULL_FACE); glFrontFace(GL_CW); glLineWidth(1.0f); // glDisable(GL_DITHER); glEnable(GL_LINE_SMOOTH); glEnable(GL_MULTISAMPLE); glViewport(0,0,m_width , m_height); m_camera = m_cameraController.toMatrix(); QVector3D lightDirection; switch (m_currView) { case TopView: lightDirection = QVector3D(0.0,0.0,1.0); break; case BottomView: lightDirection = QVector3D(0.0,0.0,-1.0); break; case LeftView: lightDirection = QVector3D(-1.0,0.0,0.0); break; case RightView: lightDirection = QVector3D(1.0,0.0,0.0); break; case FrontView: lightDirection = QVector3D(0.0,-1.0,0.0); break; case BackView: lightDirection = QVector3D(0.0,1.0,0.0); break; } lightDirection.normalize(); QVector3D directionalColor = QVector3D(0.3,0.3,0.3); QVector3D ambientLight = QVector3D(0.5,0.5,0.5); m_world.setToIdentity(); m_world.translate(m_modelBox.getCenterPoint()); m_world.rotate(m_rotation); m_world.scale(1.0f, 1.0f, m_worldZScalar); m_world.translate(-m_modelBox.getCenterPoint()); QMatrix3x3 normalMatrix = m_world.normalMatrix(); if(geometries){ if(!m_drawWireFrame){ m_programGrid->bind(); //Set MVP Uniforms m_programGrid->setUniformValue(m_projMatrixLoc, m_proj); m_programGrid->setUniformValue(m_mvMatrixLoc, m_camera * m_world); m_programGrid->setUniformValue(m_normalMatrixLoc, normalMatrix); //Set Lighting Uniforms. m_programGrid->setUniformValue(m_lightDirectionLoc, lightDirection); m_programGrid->setUniformValue(m_directionalColorLoc, directionalColor); m_programGrid->setUniformValue(m_ambientColorLoc, ambientLight); //Draw Grid Geometry geometries->drawGeometry(m_programGrid); m_programGrid->release(); //Draw Border Lines if(m_showBorders){ m_programLines->bind(); m_programLines->setUniformValue(m_projMatrixLocLines, m_proj); m_programLines->setUniformValue(m_mvMatrixLocLines, m_camera * m_world); geometries->drawLines(m_programLines, QVector3D(0.0,0.0,0.0)); m_programLines->release(); } }else{ m_programLines->bind(); m_programLines->setUniformValue(m_projMatrixLocLines, m_proj); m_programLines->setUniformValue(m_mvMatrixLocLines, m_camera * m_world); geometries->drawLines(m_programLines, QVector3D(1.0,1.0,1.0)); m_programLines->release(); } } if(wellgeometries){ glLineWidth(4.0f); m_programLines->bind(); m_programLines->setUniformValue(m_projMatrixLocLines, m_proj); m_programLines->setUniformValue(m_mvMatrixLocLines, m_camera * m_world); wellgeometries->drawLines(m_programLines, QVector3D(1.0,0.0,0.0)); m_programLines->release(); } if(m_showCompass){ glDisable(GL_DEPTH_TEST); glViewport(0,0,100,100); m_world.setToIdentity(); m_world.translate(0,0,-5); m_world.rotate(m_cameraController.rotation().inverted()); m_world.rotate(m_rotation); QMatrix4x4 proj; // Set near plane, far plane , field of view const qreal zNear = 1.0f, zFar = 150.0f, fov = 45.0; proj.setToIdentity(); proj.perspective(fov, 1.0f, zNear, zFar); m_programGrid->bind(); m_programGrid->setUniformValue(m_projMatrixLoc, proj); m_programGrid->setUniformValue(m_mvMatrixLoc, m_world); m_programGrid->setUniformValue(m_normalMatrixLoc, normalMatrix); //Set Lighting Uniforms. m_programGrid->setUniformValue(m_lightDirectionLoc, lightDirection); m_programGrid->setUniformValue(m_directionalColorLoc, directionalColor); m_programGrid->setUniformValue(m_ambientColorLoc, ambientLight); compass->drawCompassGeometry(m_programGrid); m_programGrid->release(); } //doneCurrent(); }

QOpenGLWidget is works into an FBO. Probably the surface format was set to multisampled therefore the underlying FBO inherited that and reading GL_DEPTH_COMPONENT from a multisampled FBO is not possible. To check this set samlpes to zero in QSurfaceFormat and pass it to QOpenGLWidget.

There's no need to call makeCurrent() in the virtual GL methods. It's already done for you before they are called and doneCurrent() is called for you after they finish. See the docs for these methods.

Hello, I know they don't inherit one another, that's why I'm asking if it's possible. :) I have a form with QOpenGLWidget laid out and want to use Qt3D, which does require a QWindow subclass for its painting routines. Now I was thinking maybe creating an attached QOpenGLWindow and sharing contexts but I'm not quite sure if this is the way. Anyway, createWindowsContainer is a possible solution, but I'd need to handle the layout insertion manually, this is why I'm asking. Kind regards.