[Development] OpenGL Support in Qt5

[Sean Harmer]

Hi Gunnar,

On Monday 16 July 2012 10:00:03 gunnar.sletta at nokia.com wrote:
> Compatibility between ES and desktop needs to be handled for these classes
> to be used in Qt. For the core set that Qt/QML currently uses, this is
> already handled by QOpenGLFunctions.

ES does not support geometry shaders and the like (at least yet) so these have 
been handled differently in the past.

Yes the QOpenGLFunctions class provides (nearly all) ES2 functions but it does 
not allow Qt or 3rd party developers to take advantage of additional features 
on the desktop (if present). Think instanced geometry for rendering many QQ2 
items of the same type or GPU powered particles using transform feedback 
streams etc (no idea if these are already used or not).

It is possible to #ifdef out such code when compiling Qt for OpenGL ES and 
still provide richer functionality for desktop systems. QtQuick2 itself 
doesn't necessarily have to make use of it - although it could do to provide 
additional features or take advantage of performance improvements on desktop 
systems - but it opens the door for applications developers using Qt and 
OpenGL.

> > As for the symbol count, I agree that this is an issue. I am open to
> > suggestions on how to handle this. We could make it an optional feature
> > enabled at configure time; somehow look at factoring it out into a new
> > QtOpenGL library (not the existing widget based one) so that it is only
> > linked in if people really want it. Although in those cases Qt itself
> > would not be able to use it.
> > 
> >> Because the functions are not a well defined subclass hierarchy (and nor
> >> can they be), the user will have to make a compile-time decision about
> >> which version to code against, making the code less flexible at runtime.
> >> Will this be a problem?
> > 
> > Why are they not a well-defined class hierarchy? The only assumption I
> > have
> > made in the suggested hierarchy is that a Core profile context is forwards
> > compatible and a Compatibility profile context is not forwards compatible
> > (i.e. still has deprecated functions present). With this small simplifying
> > assumption the class hierarchy seems to be well-defined - unless you have
> > spotted something I have missed of course?
> 
> The problem is mostly the 3.1 profile, as it sits completely outside the
> hierarchy.

Indeed, which is why I treat the QOpenGLFunctions_3_1 class as a special case.

Cheers,

Sean