[osg-users] a question on extension functions convention

[Sergey Kurdakov]

Hi Robert,

you might notice, that I try to make a port of osg to emscripten

Overall osg 'for  the web'  works, but I found several issues with
emscripten which require me to keep
quite a different copy of osg

The main issue are  extensions.

The problem arises from how emscripten translates OpenGL to WebGL calls.

it takes

gl* functions in C code and directly substitutes them  with webgl gl*
functions.

Now it is clear what the problem is : that emscripten compiler does not
understand extension functions which are set in the way

setGLExtensionFuncPtr(_gl*

let's take an example:

void Texture2DArray::Extensions::glTexSubImage3D( GLenum target, GLint
level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei
height, GLsizei depth, GLenum format, GLenum type, const GLvoid *pixels)
const
{
    if (_glTexSubImage3D)
    {
        _glTexSubImage3D( target, level, xoffset, yoffset, zoffset, width,
height, depth, format, type, pixels);
    }
    else
    {
        OSG_WARN<<"Error: glTexSubImage3D not supported by OpenGL
driver"<<std::endl;
    }
}

_glTexSubImage3D function won't be translated ,

There are different ways to keep emscripten happy and use that
glTexSubImage3D and I have forced it.
But the ways how i did so far - looks patchy and inconsistent ( lots of
'#ifdef's where calls to extensions occur )

And I would like to have an osg port which is minimally different from
stock osg ( just ifdef ed threading functions - there are no threads in
browser and there will not be any similar threading functions to one used
in osg for foreseeable future ).

the  solution which will satisfy emscripten with least invasive way seems
to have

Extensions::_gl

functions everywhere and also

setGLExtensionFuncPtr(gl*  //no _ before gl

approach to set extensions.

and for setGLExtensionFuncPtr - for emscripten there will be a special
function to deal with what gl functions WebGL has and what not.

of cause I understand - such a change might break quite a bit of user code
in case I develop a patch for osg which follows  such convention

I have several other ways to deal - to write a special emscripten module
which will be clever enough to use both gl and _gl functions during
translation phase, but then - it is hardly possible that it will be
accepted to emscripten as it will be needed only for my port and any user
will need to hack emscripten to compile osg for web.

so my question is - how feasible is to ask for _gl gl convention swap for
extention _gl* functions and their Extensions::gl* wrappers?

Best regards
Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150410/44338b70/attachment-0001.htm>