[Development] OpenGL in Qt 5.1 and onwards

[Sletta Gunnar]

On Dec 18, 2012, at 2:34 PM, Sean Harmer <sean.harmer at kdab.com> wrote:

> Hi,
> 
> I would like to start a discussion on the future level of support for OpenGL 
> enablers in Qt for those that are interested. So here goes...
> 
> I would like to add in a bunch more OpenGL enablers but am not sure on where 
> to best put them. Some things I have in mind are:

Hi Sean,

Late reply, but I think all in all this is great. I would like to draw the line at 3D scene graph and model loaders and similar as I think this falls outside the scope of the module, but anything that makes OpenGL easier to use has my vote.

> 
> 1) Classes that contain member functions for all OpenGL functions of a given 
> version and profile. E.g. no need to use GLEW or similar. WIP version of this 
> at 
> 
> https://codereview.qt-project.org/#change,35408
> 
> This needs resubmitting against dev of course which I will do after some 
> refactoring of the underlying code-generator and trying an experiment with a 
> different inheritance hierarchy.
> 
> Where should this live? It fits in nicely with obtaining pointers to such 
> objects directly from QOpenGLContext. However, it does add size to QtGui so 
> some people may object to this being located there. The vast majority of 
> functions are inline. The other option is to put it into a Qt3D OpenGL-enabler 
> library and create the objects via some factory class.
> 
> At present I have a bunch of other WIP patches based upon this work but they 
> could be refactored to resolve the necessary GL functions themselves. Using 
> these classes would make the others easier to implement but not impossible 
> without.

How much does this add to the library size when they are not used? One scenario for QtGui is to "give an OpenGL and an OpenGL context only". I'm thinking especially about embedded and low-end where library size might still matter. Could/should we put these behind an ifdef? Either !QT_OPENGL_ES or something else? 

> 
> 2) An QOpenGLVertexArrayObject class. This would be just a thin wrapper around 
> a VAO with possibly some API to make it easier to use with QOpenGLBuffer and 
> QOpenGLShaderProgram. 
> 
> This could potentially find use in QtQuick 2 so putting it in QtGui alongside 
> the other QOpenGL* classes makes sense. I think the lack of VAO's in 
> qtdeclarative is what makes it necessary to still use a compatibility profile 
> with QtQuick 2. This limits the GL features we can use in conjunction with QQ2 
> on Mac as Apple only implement the Core Profile for GL 3.x. That is another 
> story though.

Could you elaborate on this problem? I'm not familiar with it?

Qt Quick 2 will continue to use the golden subset of OpenGL 1/2/3/4 and OpenGL ES 2.0 that it currently uses for the foreseeable future, but then again, there is very little actual OpenGL in the public API. It would of course be possible to write a special renderer making use of certain desktop OpenGL features if these add significantly to the performance.

> 
> 3) OpenGL occlusion and timing query objects. Again these are good candidates 
> for QtGui I think but if people object they could go into Qt3D again. The 
> timing query object in particular would be valuable for profiling the GPU time 
> spent in rendering QtQuick 2 scenes. Iirc then right now only the CPU time is 
> available in qtdeclarative but that is only half the story for profiling this 
> stuff.
> 4) Transform feedback object. Another small but useful candidate for inclusion 
> in QtGui. These objects allow you to perform calculations on the GPU and write 
> the results to a bound buffer object before the rasterisation stage. This can 
> be used to perform animation updates for particles or physical simulations on 
> the GPU for example. The output buffer is then used in a second pass to render 
> with the calculated parameters. Would be very nice to integrate with 
> QOpenGLBuffer and QOpenGLShaderProgram again.
> 5) Provide support for Geometry, Tessellation Control, Tessellation Evaluation 
> and Compute Shader support in QOpenGLShaderProgram. I don't see anything 
> contentious with these. They are just extending QOpenGLShader and/or 
> QOpenGLShaderProgram.
> 
> 6) Integrate support for the GL_ARB_debug_output extension into the Qt debug 
> message system. Peppe has said he will start to look at this shortly and I 
> think this would be an awesome feature to have available where the extension 
> is supported.


yep, these all sounds great.

> 
> 7) More enabler classes for textures, samplers, and higher-level abstractions. 
> I think these would be good candidates for a Qt3D library, unless someone 
> would really like to see a subset in QtGui.

I think Lazlo has convinced me that a texture class in QtGui would make sense. We could then make use of it as input to textured geometry and wrap it in a QSGTexture.

> 
> Any feedback welcomed.
> 
> Cheers,
> 
> Sean
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development