On 01/15/2013 05:05 PM, Sean Harmer wrote: > On Tuesday 15 January 2013 16:37:38 Samuel Rødal wrote: >> On 01/15/2013 02:43 PM, Sean Harmer wrote: >>> 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 <[email protected]> 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. >> >> Sounds good to me to not include anything pre-QOpenGLFunctions. Then >> again I'm still not sure it's all worth to have in QtGui. Maybe a >> QtOpenGLEnablers module would be better? If so there might be less harm >> to have the earlier versions too. > > Well yes we could put these into an enablers library as part of Qt3D for > example. Hmm actually it would be better as a new small module so that QtQuick > can use them. This would mean no access from QOpenGLContext though. I would > also need to refactor the other patches to resolve needed symbols themselves. > >>> 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. >> >> Maybe it could just include the extensions that have at some point >> become standardized as part of some OpenGL version? So >> QOpenGLExtension_EXT_framebuffer_blit but not >> QOpenGLExtension_NV_bindless_texture for instance. > > The problem with that is that it kind of defeats the point of the extension > mechanism. QOpenGLExtension_NV_bindless_texture is actually a good one to pick > on as this is a feature that recent nVidia cards are capable of in hardware > but which is only available in OpenGL. Direct3D without an extension mechanism > can not provide access to this useful feature. > > The ones I would prefer to exclude are the obsolete ones, not the ones on > their way into a possible future core feature. Determining which ones go into > the obsolete set may take a little effort.
I guess I see the value in Qt providing them, it just seems a bit strange to include vendor-specific extensions. For OpenGL ES for instance there are at least NV, QCOM, ARM, AMD, IMG, and other vendor prefixed extensions. I see now that you've included most of those already, apart from the ARM ones? 3DFX extensions might be a bit obsolete these days though, who's going to write new code using those? :) Maybe a separate header for each vendor would make sense to not have such a huge header file. -- Samuel _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
