[Interest] [Qt 5, OS X] Does OpenGL 3 Core Profile work (with Qt APIs)?
Till Oliver Knoll
till.oliver.knoll at gmail.com
Mon Apr 22 10:40:08 CEST 2013
2013/4/20 James Turner <james.turner at kdab.com>:
> On 18 Apr 2013, at 09:09, Till Oliver Knoll <till.oliver.knoll at gmail.com>
> So is OpenGL 3.x Core actually supposed to work with Qt 5? Or is this
> still work in progress?
> It works fine, but the legacy QGL APIs don't help you much. Rough
> pseudo-code which works for me:
> QWindow *win = new QWindow
> win->setSurfaceType( OpenGLSurface );
> QSurfaceFormat format;
> format.setMajorVersion( 3 );
> format.setMinorVersion( 2 );
> format.setProfile( QSurfaceFormat::CoreProfile );
Thanks for the hint about QWindow/OpenGLSurface - didn't know that new
Qt 5 API yet ;)
And I figured out by now why the previously mentioned "OpenGL Windows"
example "did not work":
It uses the said QWindow API and basically re-implements the QGLWidget
"initialise-/paint-/resizeGL" functionality - without actually
rendering anything, hence my impression that "it did not work".
Still: Resizing the window of that example is *terribly* slow on my
iMac, even in release mode! It feels like 3 frames per second or even
slower (compared to the QGLWidget shown as top-level widget which
The actual code which would render a triangle is given as code
fragments in the example description itself ("Example OpenGL rendering
sub class"), even though it probably still contains "work in progress"
(or "dead") code, as in:
GLuint TriangleWindow::loadShader(GLenum type, const char *source)
// should probably be removed
It is also noteworthy that this "TriangleWindow" example given in the
Qt docs uses explicitly the attribute indices when setting them
(m_posAttr, m_colAttr) and off course uses the old Shader syntax
(prior to shader version 1.30, I guess) when declaring variables
("attribute" instead of the new "in/out" syntax).
As a matter of fact in my own example - again, derived from the
"coloring" example in
I "downgraded" the shaders to use the old syntax "attribute", added
#version 120 and used the default (on OS X) OpenGL 2.1 context - eh
voilà! The GL_INVALID error after my
disappeared! But I still got a black screen (at least without any
warning/error on the console), so there must still be something wrong
with my example code... but I have to invest some more time in that.
(I just noticed: maybe I should allocate the shader program on the
heap instead of on the stack, just like in the "TriangleWindow"
example? Maybe that would make a difference in the sense that the
underlying dynamically linked GL functions would be different,
according to the current OpenGL context)?
I yet have to try out that "TriangleWindow" example code and see
whether it actually works.
However, even it it would work and apart from the huge performance
issues: it would be of no use to me, because QWindow is not derived
from QWidget, is it? So what's the use of having a GL based windows in
a *desktop* application (except for "full-screen" usage maybe)? I
really need a QGLWidget...
And apart from QGLWidget and QGLFormat - which apparenty are /not/
deprecated in Qt 5, and I don't see any QOpenGLFormat, for instance -
I am not using any deprecated Qt OpenGL functionality AFAICT: I
replaced the QGLShaderProgram with QOpenGLShaderProgram.
My assumption/expectation is off course that QOpenGLShaderProgram
/should/ work within a QGLWidget - with a Core 3.2 GL context, that
I'll investigate more, especially I will start over from an example
that actually /does/ work from the very beginning, and try to squeeze
that into a QGLWidget with a Core 3.2 GL context, using QOpenGLShader.
In the meantime: could you confirm that you are really using a shader
version of at least 1.30 (or better yet: 1.50) with the new in/out
(as opposed to the version where you pass the attribute /index/ as
parameter) work for you? And are you really implying that OpenGL 3.2
(or above) is officially not supported with QGLWidget - at least not
with the "Qt OpenGL API"?
Oh, and with respect to "in vec4 color" vs "in vec3 color": I assume
that the Qt API will properly define the array passed along by
QVector<QVector3D> with a corresponding call to glVertexAttribPointer,
and the OpenGL vertex shader will fill the missing values in a "vec4"
defintion with default values, right? So the initial "color" example
by Digia should work correctly in that respect (passing along Vector3D
data when the shader expects a vec4)? The last point is off course an
OpenGL related question only (the new "Red Book" covering OpenGL 4.3
is already on the way ;))
More information about the Interest