Hi Sherman et. al,

The reason for the different in SVN head/2.6.0 is that by default the
Viewer::renderingTraversals() now does a release context, this is done
to fix a problem that was occuring when users were serializing
multiple multiple viewers in a single frame loop - so had multiple
calls to renderinTraversals() on different windows.  In ViewerBase
you'll now find:

        /** Hint to tell the renderingTraversals() method whether to
call relaseContext() on the last
          * context that was made current by the thread calling
renderingTraverals().  Note, when
          * running multi-threaded viewer no threads will be made
current or release current.
          * Setting this hint to false can enable the frame loop to be
lazy about calling makeCurrent
          * and releaseContext on each new frame, helping performance.
 However, if you frame loop
          * is managing multiple graphics context all from the main
frame thread then this hint must
          * be left on, otherwise the wrong context could be left
active, introducing errors in rendering.*/
        void setReleaseContextAtEndOfFrameHint(bool hint) {
_releaseContextAtEndOfFrameHint = hint; }

        /** Hint to tell the renderingTraversals() method whether to
call relaseContext().*/
        bool getReleaseContextAtEndOfFrameHint() const { return
_releaseContextAtEndOfFrameHint; }

This allows you to switch off this release context if you wish, and
then you'll still have the graphis context current when in Single
Threaded rendering, however, I'd suggest to is not to considered a
good practice as such code can easily be broken by changing the
threading model.

My recommendation is that all users avoid doing OpenGL calls directly
in the frame loop, and instead use a Camera initial/pre/post/final
draw callback to do extra OpenGL calls.  This approach works for all
threading models and viewer configurations.

Robert.

On Thu, Jul 31, 2008 at 5:45 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
>> Thanks for the reply - I am running osgViewer in single threaded mode
>> - still returns NULL. The drawable trick works as expected,
>> but I don't understand why this doesn't work in the main
>> render loop when in single threaded mode. I *think* this
>> worked in 2.4. Almost positive.
>> Anyway, here's a simple example. glGetString fails in the
>> loop but succeeds in the drawable. Note the usage of single
>> threaded mode. I'm not so concerned about having to move this
>> code to a drawable, but perhaps this is indicative of a larger issue?
>
> I agree it seems odd that you don't have a current context in this case. To
> understand the issue, try setting a breakpoint at the MakeCurrent call;
> somewhere up the call stack, you should find an explanation for why it is
> being set to NULL each frame.
>
> Another option for you is to use a camera post draw callback; it is executed
> while the draw thread has a current context.
>   -Paul
>
> _______________________________________________
> 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

Reply via email to