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
