[Development] QT5 OpenGL question

Sat Aug 3 11:16:56 CEST 2013

QOpenGLFunctions shouldn't be selective since it states that it provides
access to the GLES2 API for users to be able to use the GLES2 API (on the
desktop), providing random/selective functions from GLES2 would be silly,
missing a core function like glClear() would be even more silly, so I'm
pretty sure it's a bug. Do I have to file a bug?

And in reply to Giuseppe D'Angelo: QOpenGLFunctions must deal with this
issue, not me, glClear can't be available "by default" because it like any
other gl function is context specific, if it would be as you say then
QOpenGLFunctions_3_2_Core and other classes would not be providing glClear
either, but they do provide it.

On Sat, Aug 3, 2013 at 11:48 AM, Sean Harmer <sh at theharmers.co.uk> wrote:

>  On 02/08/2013 22:30, Jiergir Ogoerg wrote:
>
>  Also,
> QOpenGLFunctions doesn't have a glClear() function while being advertised
> as "The QOpenGLFunctions class provides cross-platform access to the
> OpenGL/ES 2.0 API" but GLES2.0 does have a glClear() function.
>
>  Is it a bug?
>
>  Other classes like QOpenGLFunctions_2_1 and QOpenGLFunctions_3_2_Core do
> have such a function.
>
>
> QOpenGLFunctions is selective about which GL functions is exposes. I do
> not know the reasoning behind the choices of functions as it was before my
> time.
>
> The QOpenGLFunctions_<MAJOR>_<MINOR>[_PROFILE] aim t be 100% complete so
> if you spot any missing functions on those please report a bug. Yes, I will
> be adding support for OpenGL 4.4 in Qt 5.2.0. I don't have any concrete
> plans yet to add support for ES 3 as I don't have access to any ES 3
> hardware yet.
>
> Cheers,
>
> Sean
>
>
>
>
>  On Fri, Aug 2, 2013 at 9:35 PM, Jiergir Ogoerg <f35f22fan at gmail.com>wrote:
>
>>   Thanks both of you, I see now, GL is old (1993 I guess) and it shows,
>> e.g. it requires creating a context on windows before even being able to
>> query GL info etc.
>>
>> What do you think of the new Linux GL ABI proposal from Nvidia:
>> https://github.com/aritger/linux-opengl-abi-proposal
>>
>>  I recall doing some WebGL work a month ago (I forgot about) and I ran
>> into the same issue - couldn't use the same "gl" on multiple GL canvas on
>> an html5 page,
>>  but in WebGL the function names are stripped of the "gl" prefix so you
>> don't have to repeat yourself like gl.glUseProgram, just gl.UseProgram -
>> with
>> Qt5 I'd have to use the former, unfortunately, but not a big deal.
>>
>>
>>
>> On Fri, Aug 2, 2013 at 3:21 PM, Sean Harmer <sean.harmer at kdab.com> wrote:
>>
>>> Hi,
>>>
>>> On Friday 02 August 2013 15:01:05 Jiergir Ogoerg wrote:
>>> > Thanks, but it's better to use functions wrapped in namespaces when
>>> it's
>>> > possible (for example - according to Google's C++ coding style)
>>> instead of
>>> > static methods in classes or methods of class instances or any other
>>> > solution when you can just use functions wrapped in namespaces.
>>> > And no, Qt5 doesn't allow using glew.
>>> >
>>> > On your later point - could you please elaborate on why you need the GL
>>> > function addresses to be context-specific? I've used freeglut and GLFW
>>> > before and never cared of had issues with this.
>>>
>>>  Please see:
>>>
>>> http://www.opengl.org/wiki/Load_OpenGL_Functions
>>>
>>> and
>>>
>>>
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/dd374386(v=vs.85).aspx
>>>
>>> Cheers,
>>>
>>> Sean
>>>
>>> >
>>> > On Fri, Aug 2, 2013 at 1:44 PM, Sean Harmer <sean.harmer at kdab.com>
>>> wrote:
>>> > > On Friday 02 August 2013 10:05:56 Sze Howe Koh wrote:
>>> > > > On 2 August 2013 08:16, Jiergir Ogoerg <f35f22fan at gmail.com>
>>> wrote:
>>> > > > > Hi,
>>> > > > > I'm willing to switch to QT5 with GL,
>>> > > > > afaik in Qt5 the GL functions are encapsulated into a class that
>>> > >
>>> > > extends
>>> > >
>>> > > > > QAbstractOpenGLFunctions and you can't use the GL calls outside
>>> that
>>> > >
>>> > > class
>>> > >
>>> > > > > unless you pass each time a reference to this class.
>>> > > > >
>>> > > > > Why doesn't it publish the GL functions publicly (not inside a
>>> class
>>> > > > > instance) like glew and other tools do?
>>> > > > >
>>> > > > > I'm asking because I have a lib of mine that uses GL calls, what
>>> > >
>>> > > should I
>>> > >
>>> > > > > do, pass an instance of OpenGLFunctions class to each method in
>>> the
>>> > >
>>> > > lib? -
>>> > >
>>> > > > > that's cumbersome.
>>> > > >
>>> > > > Hi,
>>> > > >
>>> > > > To answer your second question, you could use a global pointer to a
>>> > > > QOpenGLFunctions_X object -- no need to pass it as around as an
>>> > > > argument.
>>> > >
>>> > > Or set it as a member variable in that class. Or inherit your class
>>> from
>>> > > QOpenGLFunctions_blah. Or you could resolve global functions
>>> yourself. Or
>>> > > maybe use GLEW - although I've not tried that with Qt for a while
>>> now.
>>> > >
>>> > > The reason we have these functions on a class rather than globally
>>> is that
>>> > > the
>>> > > function addresses can be context-specific.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > Sean
>>> > > --
>>> > > Join us in October at Qt Developer Days 2013 -
>>> https://devdays.kdab.com
>>> > >
>>> > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
>>> > > 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
>>> --
>>> Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com
>>>
>>> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
>>> 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
>>>
>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130803/f43628c6/attachment.html>