Hi Robert, Thanks for your response. I will play with a few options and send you a patch for which works best.
-Alok On Fri, Apr 23, 2010 at 1:56 AM, Robert Osfield <[email protected]> wrote: > Hi Alok, > > Interesting issue... when I implemented the GLES support I did so with > assumption of dynamic GL libs, and with the aim of minimizing the code > differences between the various OpenGL targets - hence the use of > functions pointers for all targets. You are of course correct that > when compiling directly against GLES2 and GL3 the shader functions > don't need to be queried at runtime, and calling them directly is > possible and actually desirable as the OSG's extension mechanism > breaks down for static linking of GL. > > So the question then is how to satisfy the goal of minimizing code > differences between the various OpenGL targets and enabling static > linking of GL libs. Possibilities are: > > 1) Disable the extension function mechanism when GL is statically > linked, for this we'll need to add an extra > CMake option to tell the build to use a different code path when > getting the function pointers. Have the > static link version return NULL. This solution will need one of > the following changes as well to complete the > job. > > 2) A possible variation on 1) - but instead of return NULL use a > hardwired map between function > name strings to function pointers to the actual functions. > > 3) Use of built-in functions in place of extension->glFunction() > style calls, using an #if #else #endif block. > > 4) or change of the extension classes to call the built-in directly > rather than the via the function pointer. > > Options 3 and 4 would require 1 to implemented as well, while 2 is a > bit devious/hacky wouldn't require any other changes to the OSG. > > Option 3 is most intrusive to the rest of the OSG codebase as it > doesn't localise the changes at all - the #if #else #endif blocks get > carried out across the OSG, unless you use macro that are defined in > the extension headers, in which case you are in similar place to 4... > > Option 2 & 4 have an advantage that they keep the changes localised, > in the case of 2 the changes are all embedded into the > GLExtensions.cpp, in the case of 4 each relevant Extension class > header will need modifying. Performance wise Option 4 has it, and > given performance is more of an issue in the embedded space once can > probably conclude that this probably the best route. > > Thoughts? > Robert. > > On Thu, Apr 22, 2010 at 7:20 PM, Alok Priyadarshi <[email protected]> wrote: >> I have been working on porting OSG to NativeClient - >> http://code.google.com/p/nativeclient/ >> >> NativeClient allows STATIC linkage to a custom OpenGL ES 2.0 library. >> OSG requires dynamic GLESv2 libs. I am looking for a way to make OSG >> work with static linking. I am also volunteering to do the actual work >> with some guidance. >> >> It seems for OSG_GLES2_AVAILABLE and OSG_GL3_AVAILABLE there is no >> need to call built-in functions (glCreateShader, etc) through the >> extension mechanism. The built-in functions can be called directly >> eliminating the need for LoadLib + ProcAddress. I can either change >> osg::GL2Extensions or all the places where the built-in functions need >> to be called. These functions are not extensions anymore anyway. >> Ideas? >> >> Thanks, >> -Alok >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
