I used osgSetGLExtensionsFuncPtr to remove the symbols. I don't know how to test this path, but it did remove the symbols from libosgViewer.so. I have also not been able yet to see if that was sufficient for our customer.
I did this by looking at other cases, and I tried to follow some of the same practices in PixelBufferX11, like using _useSGIX in a similar way to the previous _useGLX1_3."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15041 16af8721-9629-0410-8352-f15c8da7e697
> quote from http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt
> The following attributes are supported by wglCreatePbufferARB:
>
> WGL_PBUFFER_LARGEST_ARB If this attribute is set to a
> non-zero value, the largest
> available pbuffer is allocated
> when the allocation of the pbuffer
> would otherwise fail due to
> insufficient resources. The width
> or height of the allocated pbuffer
> never exceeds <iWidth> and <iHeight>,
> respectively. Use wglQueryPbufferARB
> to retrieve the dimensions of the
> allocated pbuffer.
It notifies the user when the size is not as requested, but I could find no way for the program to detect this. I've added two lines to write the new size back into the _traits, I think this is appropriate, but I am not absolutely sure.
In PixelBufferX11 was no support, so I've added GLX_LARGEST_PBUFFER(_SGIX) support, with the same writeback to the _trais.
I have tested the GLX_LARGEST_PBUFFER version on linux and the WGL_PBUFFER_LARGEST_ARB with windows, all tested with the modified autocapture I just submitted.
"autocapture --pbuffer --window 100 100 18192 18192 cow.osg.\[0,0,-22.7\].trans"
gives me a 4096x4096 image on my windows machine,
and a 8192x8192 image on linux."
osg::GraphicsContext, in order to give good integration with the
application's GUI toolkit. This works really well.
However, I need to share OpenGL texture resources with the standard
osgViewer GraphicsContext implementations, in particular the
PixelBuffers. This is essential for my application to conserve graphics
memory on low-end hardware. Currently the standard osg implementations
will not share resources with another derived osg::GraphicsContext,
other than the pre-defined osgViewer classes e.g. PixelBufferX11 is
hardcoded to only share resources with GraphicsWindowX11 and
PixelBufferX11 objects, and no other osg::GraphicsContext object.
To address this in the cleanest way I could think of, I have moved the
OpenGL handle variables for each platform into a small utility class,
e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11
and any other derived osg::GraphicsContext class can inherit from
GraphicsHandleX11 to share OpenGL resources.
I have updated the X11, Win32 and Carbon implementations to use this.
The changes are minor. I haven't touched the Cocoa implmentation as
I'm not familiar with it at all and couldn't test it - it will work
unchanged.
Without this I had some horrible hacks in my application, this greatly
simplifies things for me. It also simplifies the osgViewer
implementations slightly. Perhaps it may help with other users'
desires to share resources with external graphics contexts, as was
discussed on the user list recently."
Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
pbuffer functions or exactly ask for the extensions we need to call the
apropriate glx extension functions for and around pbuffers extensions.
The glx 1.3 version of this functios are prefered. If this is not pressent we
are looking for the glx extensions and check for them.
Prevously we just used some mix of the glx 1.3 functions or the extension
functions without making sure that this extension is present.
"
