Hi Robert,
It seems this modification has broke the Compile Contexts (see my post Win32
problems with CompileContext).
Currently an application setted to use compile contexts crash with a
glGetString call.
On Sun, Aug 3, 2008 at 3:30 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:
> 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
> > osg-users@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
Serge Lages
http://www.tharsis-software.com
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
