[Development] OpenGL in Qt 5.1 and onwards

[Sean Harmer]

Hi,

On Monday 07 January 2013 10:00:47 Sean Harmer wrote:
> On Monday 07 January 2013 08:28:35 Sletta Gunnar wrote:
> > 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.
> 
> No problem and Happy New Year!
> 
> > 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?
> 
> I'll get some numbers put together and report back shortly but the code
> already has a #ifdef QT_OPENGL_ES_2 to remove the desktop version-specific
> and extension classes.

New version of the corresponding patch against dev is at:

https://codereview.qt-project.org/#change,44783

I have the numbers for a size comparison now. For a release build of QtGui 
from the dev branch on 64-bit Linux I have:

-rwxr-xr-x 1 sean_harmer users 4084848 Jan 14 11:01 libQt5Gui.so.5.0.1

With all of the extension and OpenGL versions classes in this grows to

-rwxr-xr-x 1 sean_harmer users 4781168 Jan 14 15:42 libQt5Gui.so.5.0.1

A delta of 696,320 bytes. 

Gunnar/Samuel, I guess it is up to you guys whether to allow this into QtGui 
or not. There are some knobs we can tweak to reduce the size somewhat though 
so this is an absolute upper limit:

1) Don't bother including classes for legacy versions of OpenGL (1.0-2.1). 
This eliminates approximately one half of the inheritance hierarchy in the 
classes introduced for OpenGL versions. This should be fine to live with as 
QOpenGLFunctions already makes most common functions available. Also, new code 
should really not be using these legacy API's. So really these are just there 
for completeness. Could leave them in the source but have them compiled out by 
default via a #ifdef.

2) Do not include all extension classes. We could identify the most commonly 
used extensions (somehow) and only include those by default. Again we could 
allow someone to opt-in to other extensions, either globally or on a case-by-
case basis using #ifdefs. Again this should be feasible as many extensions are 
essentially deprecated by having been merged into the core features of newer 
versions or have been superseded by new core features.

If a user compiles their own Qt with either the legacy version classes or 
additional extension classes then the obligation would be on them to ship a 
suitable Qt with their application as they would be using a non-standard 
build.

If you wish to cut the size down I can investigate these options in more 
detail.

<snip>
> I now have WIP patches for Geometry, Tessellation Control, Tessellation
> Evaluation shader support. I'll work on the Compute shaders once I learn how
> to use them (only just got hold of capable drivers). Still needs some API
> clean-up and docs etc.
> 
> I also have a WIP patch for OpenGL timer query objects (single and sets of
> them) and am now working on a higher-level abstraction for measuring
> rendering times and receiving the query results asynchronously one or more
> frames later. I need a good class name though, QOpenGLMultiFrameTimer?
> 
> I will push these to gerrit soon but they already work.

Patches for a few things here...

Geometry shaders:
https://codereview.qt-project.org/#change,44784
https://codereview.qt-project.org/#change,44785

Vertex Array Objects:
https://codereview.qt-project.org/#change,44786

Tessellation Shaders:
https://codereview.qt-project.org/#change,44787

Timer Queries (still needs higher level helper):
https://codereview.qt-project.org/#change,44788

Example of tessellation and geometry shaders (for wireframe) using these 
patches here:

http://www.kdab.com/~sean/tessellation-03.png

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